Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

FDA Focus on Design Controls

3,789 views

Published on

Design controls are not an easy subject to address during and after the design of medical devices and manufacturing processes. Design controls should drive the device design process, not be an afterthought. This session focuses on treating design as a separate entity within the quality management system, user needs vs. design inputs, continuation of design controls after the transfer process, design review and more.

  • Sex in your area is here: ❤❤❤ http://bit.ly/2Qu6Caa ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Follow the link, new dating source: ❤❤❤ http://bit.ly/2Qu6Caa ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Secrets To Working Online, Hundreds of online opportunites you can profit with today! ♣♣♣ https://tinyurl.com/y4urott2
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

FDA Focus on Design Controls

  1. 1. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 1 OMTEC 2016 John Gagliardi MidWest Process Innovation, LLC FDA Focus on Design Controls (decision-making / approaches / objective evidence) 21 CFR, Part 820.30
  2. 2. ©MPI, LLC 2016 all rights reserved. MidWest Process Innovation, LLC Design Controls Begin Concept & Feasibility Risk Analysis Begins Manufacturing Scale-up Design Review Design Review Design Review Design Pilot Mfring. Phase Product And Process Release Inputs Inputs Inputs Transfer Design Changes Begin Design History File Sales and Distribution Product History Outputs OutputsOutputs Design Controls Device Master Record Device History Record Design History File Verification Quality Review Board Design Validation Planning
  3. 3. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 3 “FDA Focus on Design Controls” Documented objective evidence is (always) the key to compliance….. Here’s a short list of some of the issues: • Treating design as a separate entity within the Quality Management System (QMS) • Research is not Development …..concept and feasibility is not included in design, per se • User Needs are not design inputs • Risk analysis is considered a design input…..not something that you do later on • Design Control does not end with the transfer of a design to production • The Design History File is the basis for the Device Master Record • Essential outputs must be recognized • Design Controls does not just address the Device (the product) • Design Reviews are not (necessarily) problem-solving sessions • Hallway conversations are not design reviews • Not having a cross-functional design team causes problems later on in the process • Changes to the design plan are expected (so make them when you have to) • Change can bring a company to it’s knees (when you’re not prepared for it) • Design validation using production units or their equivalents follows successful design verification • Design transfer can happen over a period of time, i.e. not necessarily all at once • Waiting too long to audit the DHF can be an “Achilles” heal
  4. 4. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 4 …..in -between _______________________________________ the lines….. _______________________________________
  5. 5. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 5 21CFR, Part 820 – Design Controls – decisions / approaches / evidence …..all devices including class I devices exempt from design controls must be properly transferred to production in order to comply with 820.181 …..the design control requirements are not intended to address concept and feasibility …..manufacturers and specifications’ developers should put together a process flow of design …..as applicable, new devices or changes to existing devices after June, 1997 must be compliant with 820.30 …..all automated devices must be developed under design controls …..the plan should reference design activities and who has the responsibility for same …..the plan is regularly reviewed and appropriately updated throughout the design process …..interfaces between organizational groups providing input to the design should be defined …..design inputs should be appropriate so that the device will perform to meet its intended use and the needs of the user …..labeling developed for a device during design should be tested for usability
  6. 6. When is Design Input Established? …..be able to tell the story and show conversion….. Design Inputs Approved (User Needs) (Design Input) Development Begins User Needs End Research Development
  7. 7. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 7 21CFR, Part 820 – Design Controls – decisions / approaches / evidence …..procedures should include a mechanism for addressing incomplete, ambiguous or conflicting requirements (design inputs) …..design inputs are to be approved by the appropriate people …..design output are the design specification which should meet design input requirements …..the outputs include the device, its, labeling and packaging associated specification and drawings, and production and quality assurance specifications and procedures  basis for the DMR …..design outputs must be documented and expressed in term that can be verified against the design input requirements …..design review(s) apply to all size companies …..design reviews must be conducted at appropriate stages of design
  8. 8. V versus v.....Medical Device meets User Needs / Outputs versus Inputs…..Design Review ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 8
  9. 9. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 9 21CFR, Part 820 – Design Controls – decisions / approaches / evidence …..design reviews must include an individual that does not have direct responsibility for the phase of design being reviewed …..prototypes can be made and used for clinical or other studies but the last and final design validation cannot be done using prototypes …..design validation follows successful design verification …..the extent of testing conducted should be governed by the risk(s) the device will present if it fails …..risk analysis is the comprehensive term for the analysis of risks presented by hazards. Risk analysis must be done (started early-on) …..it is not always possible to determine to the adequacy of the design by successfully building and testing prototypes or models produced in a laboratory setting…..testing production units under actual or simulated use conditions prior to distribution is crucial for s/e
  10. 10. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 10 21CFR, Part 820 – Design Controls – decisions / approaches / evidence …..design transfer can take place at different stages of the design process, i.e. you don’t have to release everything “all at once” …..all design changes made after the design review that approves the initial design inputs for incorporation into the design and those changes made to correct design deficiencies once the design has been released to production must be documented …..while change is a healthy and necessary part of product development, quality can be ensured only if change is controlled and documented in the development process …..each manufacturer must establish criteria of evaluating changes to ensure that the changes are appropriate and based upon risk …..the DHF is the basis for the DMR. A complete history of the design controls process must be documented. DHF DMR Design Plan DHF
  11. 11. Thank You John Gagliardi MidWest Process Innovation, LLC www.MPILLC.co JGAGL777@One.Net ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 11
  12. 12. Notes: ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 12
  13. 13. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 13 Full Quality System…..Applications Approach The FDA requires that domestic or foreign manufacturers have a quality system for the design and production of Class II, Class III and some Class I medical devices intended for commercial distribution in the United States
  14. 14. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 14 Scope…..Impact on Device Life Cycle…..linkages The QS regulation is in Part 820 of Title 21 of the Code of Federal Regulations (CFR). This regulation covers (at least): •quality management and organization •auditing •training •device design •acceptance activities •purchasing controls / acceptance activities •production and process controls and ancillary processes •packaging and labeling control •device evaluation •handling, storage, distribution •corrective action and preventive action •non-conforming product •complaint handling •servicing and installation •document control and records •statistical techniques
  15. 15. Research vs. Development Some manufacturers have difficulty in determining where research ends and development begins. Research activities may be undertaken in an effort to determine new business opportunities or basic characteristics for a new product. It may be reasonable to develop a rapid prototype to explore the feasibility of an idea or design approach, for example, prior to developing design input requirements. But manufacturers should avoid falling into the trap of equating the prototype design with a finished product design. Prototypes at this stage lack safety features and ancillary functions necessary for a finished product, and are developed under conditions which preclude adequate consideration of product variability due to manufacturing. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 15
  16. 16. Concept and Feasibility – User Needs Some members of the medical device community view these marketing memoranda, or the equivalent, as the design input. However, that is not the intent of the quality system requirements. Such concept documents are rarely comprehensive, and should not be expected to be so. Rather, the intent of the quality system requirements is that the product’s conceptual description be elaborated, expanded, and transformed into a complete set of design input requirements which are written to an engineering level of detail. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 16
  17. 17. Concept and Feasibility – User Needs – R is NOT D This is an important concept. The use of qualitative terms in a concept document is both appropriate and practical. This is often not the case for a document to be used as a basis for design. Even the simplest of terms can have enormous design implications. For example, the term "must be portable" in a concept document raises questions in the minds of product developers about issues such as size and weight limitations, resistance to shock and vibration, the need for protection from moisture and corrosion, the capability of operating over a wide temperature range, and many others. Thus, a concept document may be the starting point for development (and coming from Research), but it is not the design input requirement. This is a key principle-the design input requirements are the result of the first stage of the design control process. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 17
  18. 18. Scenario-Based Approach to understanding this step-by-step relationship An analogy to automobile design & development may help to clarify these concepts. Fuel efficiency is a common design requirement. This requirement might be expressed as the number of miles-per-gallon of a particular grade of gasoline for a specified set of driving conditions. As the design of the car proceeds, the requirements, including the one for fuel efficiency, are converted into the many layers of system and subsystem specifications needed for design As these various systems and subsystems are designed, design verification methods are used to establish conformance of each design to its own specifications Because several specifications directly affect fuel efficiency, many of the verification activities help to provide confirmation that the overall design will meet the fuel efficiency requirement. This might include simulated road testing of prototypes or actual road testing. This is establishing by objective evidence that the design output conforms to the fuel efficiency requirement. However, these verification activities alone are not sufficient to validate the design. The design may be validated when a representative sample of users have driven production vehicles under a specified range of driving conditions and judged the fuel efficiency to be adequate. This is providing objective evidence that the particular requirement for a specific intended use can be consistently fulfilled. Draw a chart that progresses from user needs  initial input(s)  subsequent input(s)  verification testing fuel efficiency  36 mpg  use 94 octane gas  test octane rating comfort ride  _______ ______________ ______________ ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 18
  19. 19. V versus v.....Medical Device meets User Needs….. Outputs versus Inputs…..Review ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 19
  20. 20. Concurrent Engineering….. the reality of the “factory floor” In a traditional waterfall development scenario, the engineering department completes the product design and formally transfers the design to production. Subsequently, other departments or organizations develop processes to manufacture and service the product. Historically, there has frequently been a divergence between the intent of the designer and the reality of the factory floor, resulting in such undesirable outcomes as low manufacturing yields, rework or redesign of the product, or unexpectedly high cost to service the product. One benefit of concurrent engineering is the involvement of production and service personnel throughout the design process, assuring the mutual optimization of the characteristics of a device and its related processes. While the primary motivations of concurrent engineering are shorter development time and reduced production cost, the practical result is often improved product quality. Design Product and Process DHF DMR DHRs ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 20
  21. 21. Design Plans and Planning Comprehensive Lifecycle Approach ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 21
  22. 22. ©MPI, LLC 2016 all rights reserved. MidWest Process Innovation, LLC Design Controls Begin Concept & Feasibility Risk Analysis Begins Manufacturing Scale-up Design Review Design Review Design Review Design Pilot Mfring. Phase Product And Process Release Inputs Inputs Inputs Transfer Design Changes Begin Design History File Sales and Distribution Product History Outputs OutputsOutputs Design Controls Device Master Record Device History Record Design History File Verification Quality Review Board Design Validation Planning
  23. 23. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 23 Design Plans and Planning…..basically, a plan The design planning exercise and execution of the plans are complex because of the many areas and activities that should be covered. Some of the key activities can be: • determining and meeting the user/patients requirements; • meeting regulations and standards; • developing specifications for the device; • developing, selecting and evaluating components and suppliers; • developing and approving labels and user instructions; • developing packaging; • design reviews; • developing specifications for manufacturing processes; • verifying safety and performance of prototype and final devices; • verifying compatibility with the environment and other devices; • developing manufacturing facilities and utilities; • developing and validating manufacturing processes; • training employees; • documenting the details of the device design and processes • if applicable, developing a service program • assembly of the DHF (who, what, when, where, why and how much)
  24. 24. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 24 DHF at the Beginning…..References…..Outputs are the Basis for DMR The design controls section of the quality system requires a design history file (DHF) [820.30(j)] that contains or references the records necessary to demonstrate that the design was developed in accordance with the: 1. approved design plan, and 2. regulatory requirements Start thinking in terms of essential outputs
  25. 25. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 25 Linkages – External and Internal "The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process..." If a specific design requires support by contractors such as developing molds, performing a special verification test, clinical trials, etc., then such activities should be included or referenced in the plan and proactively implemented in order to meet the interface and general quality system requirements. The interface and general requirements also apply to needed interaction with manufacturing, marketing, quality assurance, servicing or other internal functions.
  26. 26. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 26 Simple is more appropriate – Details for specific Purposes Structure of Plans Each design control plan should be broad and complete rather than detailed and complete. The plan should include all major activities and assignments. Broad plans are: • easier to follow; • contain less errors; • have better agreement with the actual activities; and • will require less updating than detailed plans. …..put the details into protocols and work instructions
  27. 27. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 27 Design Change Notice – Authority behind changes plans require updating as the development activities dictate. Thus, the QS regulation requires in 820.30(a) that plans shall be reviewed, updated, and approved as the design and development evolves changes are considered for validation and /or verification
  28. 28. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 28 Stage-gate…..Design History File – Part of the Plan The details of updating are left to the manufacturer. The design review meetings are a good time and place to consider, discuss and review changes that may need to be made in the design development plan.
  29. 29. …..how you put design planning into play….. Discussion – using your procedure….. This might be the case, for example, if a multidisciplinary product development team is assembled for a specific project, or if the team includes suppliers, contract manufacturers, users, outside consultants, or independent auditors. TASK BREAKDOWN. The plan establishes, to the extent possible: • The major tasks required to develop the product • The major tasks required to develop the product • The time involved for each major task • The resources and personnel required • The allocation of responsibilities for completing each major task • The prerequisite information necessary to start each major task and the interrelationship between tasks • The form of each task output or deliverable • Constraints, such as applicable codes, standards, and regulations ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 29
  30. 30. Design Input Requirements Phase ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 30
  31. 31. ©MPI, LLC 2016 all rights reserved. MidWest Process Innovation, LLC Design Controls Begin Concept & Feasibility Risk Analysis Begins Manufacturing Scale-up Design Review Design Review Design Review Design Pilot Mfring. Phase Product And Process Release Inputs Inputs Inputs Transfer Design Changes Begin Design History File Sales and Distribution Product History Outputs OutputsOutputs Design Controls Device Master Record Device History Record Design History File Verification Quality Review Board Design Validation Planning
  32. 32. When is Design Input Established? …..be able to tell the story and show conversion….. Design Inputs Approved (User Needs) (Design Input) Development Begins User Needs End Research Development
  33. 33. Design Input the physical and performance requirements of a device that are used as a basis for device design 820.3(f) The term “requirement” is meant in the broadest sense, to encompass any internally or externally imposed requirements such as safety, customer-related, and regulatory requirements. All of these requirements must be considered as design inputs. Preamble #19 ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 33
  34. 34. Verification Method – e.g. the Traceability Matrix Another self-documenting verification method is the traceability matrix. This method is particularly useful when the design input and output are both documents; it also has great utility in software development. In the most common form of the traceability matrix, the input requirements are enumerated in a table, and references are provided to each section in the output documents (or software modules) which address or satisfy each input requirement. Organize your approach to design controls and objective evidence challenges ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 34
  35. 35. …..30% of the Total Project Time For complex designs, it is not uncommon for the design input stage to consume as much as thirty percent of the total project time. Unfortunately, some managers and developers have been trained to measure design progress in terms of hardware built, or lines of software code written. They fail to realize that building a solid foundation saves time during the implementation. Part of the solution is to structure the requirements documents and reviews such that tangible measures of progress are provided. Build in updates. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 35
  36. 36. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 36 Establish Design Requirements as early as possible The device specification will undergo changes and reviews as the device design evolves. However, one goal of market research and initial design reviews is to establish complete device requirements and specifications that will minimize subsequent changes.
  37. 37. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 37 DHF Old versions of the input requirements and later the input specifications are put in the design history file (DHF) or indexed in the computer as part of the DHF to help show that the design plan was followed.
  38. 38. Design Changes ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 38
  39. 39. ©MPI, LLC 2016 all rights reserved. MidWest Process Innovation, LLC Design Controls Begin Concept & Feasibility Risk Analysis Begins Manufacturing Scale-up Design Review Design Review Design Review Design Pilot Mfring. Phase Product And Process Release Inputs Inputs Inputs Transfer Design Changes Begin Design History File Sales and Distribution Product History Outputs OutputsOutputs Design Controls Device Master Record Device History Record Design History File Verification Quality Review Board Design Validation Planning
  40. 40. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 40 Separate from the Change Control in the QMS DESIGN CHANGES  Changes to a design element are controlled per 820.30(i) Design Changes which states that: each manufacturer shall establish and maintain procedures for the identification, documentation, validation or where appropriate verification, review, and approval of design changes before their implementation.
  41. 41. Change Control  Change requests and change orders should be communicated to all persons whose work might be impacted by the change.  Change control procedures should incorporate review and assessment of the impact of the design change on the design input requirements and intended uses.  Update the DHF ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 41
  42. 42. Design Changes …..all changes must be (at least) verified prior to making the change. e.g. changing the tolerance of an essential output (critical dimension) on a drawing …..changing the user need or the intended use could require a revalidation. e.g. arm support for orthopedic-related surgery…..additionally, the company wants to include shoulder surgery. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 42
  43. 43. Re-verify and / or Re-Validate the Change It is important that the design change procedures always include re-verifying and re-validating the design. Fortunately, most design changes occur early in the design process, prior to extensive design validation. Thus, for most design changes, a simple verification is all that is required. The later in the development cycle that the change occurs, the more important the re-validation review becomes. Successful verification precedes validation (or revalidation) e.g. Changing critical dimensional tolerances after validation occurs could require re-validation ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 43
  44. 44. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 44 Recap for change control…..some changes may not require re- design…..some may…..risk analysis The revised specification(s) becomes the current design goal in accordance with the manufacturer procedures for design control, design change control, and document control. A design change control procedure should at least cover: - under what conditions change control is required - documenting the reason for the change - any differences in the change control process when outside parties are involved - analysis of the design to identify other elements that are impacted by the change - for significant changes which includes any change requiring verification and/or validation, placing the reason for the change in the design history file along with the required design verification, validation and review documentation
  45. 45. Design Review ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 45
  46. 46. ©MPI, LLC 2016 all rights reserved. MidWest Process Innovation, LLC Design Controls Begin Concept & Feasibility Risk Analysis Begins Manufacturing Scale-up Design Review Design Review Design Review Design Pilot Mfring. Phase Product And Process Release Inputs Inputs Inputs Transfer Design Changes Begin Design History File Sales and Distribution Product History Outputs OutputsOutputs Design Controls Device Master Record Device History Record Design History File Verification Quality Review Board Design Validation Planning
  47. 47. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 47 Stage-gate…..Cross-functional thinking…..third party Design review [820.30(e)] is one of the key design control elements in a quality system. The objectives of design review are stated in the definition of design review in 820.3(h) as follows: Design review means a documented, comprehensive, systematic examination of a design to evaluate the adequacy of the design requirements, to evaluate the capability of the design to meet these requirements, and to identify problems.
  48. 48. Discussion The nature of reviews changes as the design progresses. During the initial stages, issues related to design input requirements will predominate. Next, the main function of the reviews may be to evaluate or confirm the choice of solutions being offered by the design team. Then, issues such as the choice of materials and the methods of manufacture become more important. During the final stages, issues related to the verification, validation, and production may predominate. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 48
  49. 49. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 49 Agenda…..Minutes…..Design Changes…..Transfer Design reviews are conducted for design definition, selection and adequacy; communication; and resolution of problems and issues.
  50. 50. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 50 Pre and Post Design Review(s) Pre- and post-review meeting significant responsibilities and assignments should be documented [820.30(b)]. These assignments are not unusual -- they are simply ordinary work required to develop a new product or modify an existing product. The progress and/or results of such assignments would typically be reported at the next review meeting.
  51. 51. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 51 DHF…..Minutes…..Plans were followed…..or not The design review meeting results are made a part of the device design history file. The results should include minutes and should include notes, or annotated draft drawings and annotated draft procedures that played a significant role during the design review. Such documents help show that plans were followed verification/validation was reviewed, and, to some extent, how the design evolved.
  52. 52. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 52 Design Changes…..Validation too early…..Successful If the validation of the final design and subsequent design review(s) reveal design problems, then design changes are required to correct these problems. Design changes require another design verification and, where appropriate, validation and review of all parts or the affected parts of the device system.
  53. 53. Design Outputs ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 53
  54. 54. ©MPI, LLC 2016 all rights reserved. MidWest Process Innovation, LLC Design Controls Begin Concept & Feasibility Risk Analysis Begins Manufacturing Scale-up Design Review Design Review Design Review Design Pilot Mfring. Phase Product And Process Release Inputs Inputs Inputs Transfer Design Changes Begin Design History File Sales and Distribution Product History Outputs OutputsOutputs Design Controls Device Master Record Device History Record Design History File Verification Quality Review Board Design Validation Planning
  55. 55. Definitions 820.3(g) Design output means the results of a design effort at each design phase and at the end of the total design effort. The finished design output is the basis for the device master record. The total finished design output consists of the device, its packaging and labeling, and the device master record. 820.3(y) Specification means any requirement with which a product, process, service, or other activity must conform. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 55
  56. 56. Discussion…..continued The first issue is important because the typical development project produces voluminous records, some of which may not be categorized as design output. On the other hand, design output must be reasonably comprehensive to be effective. As a general rule, an item is design output if it is a work product, or deliverable item, of a design task listed in the design and development plan, and the item defines, describes, or elaborates an element of the design implementation. Examples include block diagrams, flow charts, software high- level code, and system or subsystem design specifications. The design output in one stage is often part of the design input in subsequent stages. Design output includes production specifications as well as descriptive materials which define and characterize the design. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 56
  57. 57. For Example, Production Specifications Production specifications include drawings and documents used to procure components, fabricate, test, inspect, install, maintain, and service the device, such as the following: • assembly drawings • component and material specifications • production and process specifications • work instructions • quality assurance specifications and procedures • installation and servicing procedures • packaging and labeling specifications, including methods and processes used ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 57
  58. 58. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 58 DHF  basis for the DMR Design output per 820.3(g) means the results of a design effort at each design phase and at the end of the total design effort. The finished design output is the basis for the device master record. The total finished design output consists of the device, its packaging and labeling, and the device master record.
  59. 59. Design Verification and Validation ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 59
  60. 60. ©MPI, LLC 2016 all rights reserved. MidWest Process Innovation, LLC Design Controls Begin Concept & Feasibility Risk Analysis Begins Manufacturing Scale-up Design Review Design Review Design Review Design Pilot Mfring. Phase Product And Process Release Inputs Inputs Inputs Transfer Design Changes Begin Design History File Sales and Distribution Product History Outputs OutputsOutputs Design Controls Device Master Record Device History Record Design History File Verification Quality Review Board Design Validation Planning
  61. 61. Definitions 820.3(y) Specification means any requirement with which a product, process, service, or other activity must conform. 820.3(z) Validation means confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled. Process Validation means establishing by objective evidence that a process consistently (repeatable) produces a result or product meeting its predetermined specifications. Design Validation means establishing by objective evidence that device specifications conform with user needs and intended use(s). 820.3(aa) Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 61
  62. 62. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 62 SOP…..Output meets Input Requirements…..Objective Evidence DESIGN VERIFICATION Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification [820.30(f)] shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the DHF. Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.
  63. 63. Discussion – Verification – Building Design Analogy To illustrate the concepts, consider a building design analogy. In a typical scenario, the senior architect establishes the design input requirements and sketches the general appearance and construction of the building, but associates or contractors typically elaborate the details of the various mechanical systems. Verification is the process of checking at each stage whether the output conforms to requirements for that stage. For example: does the air conditioning system deliver the specified cooling capacity to each room? Is the roof rated to withstand so many newtons per square meter of wind loading? Is a fire alarm located within 50 meters of each location in the building? ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 63
  64. 64. Discussion – Validation - Building Design Analogy At the same time, the architect has to keep in mind the broader question of whether the results are consistent with the ultimate user requirements. Does the air conditioning system keep the occupants comfortable throughout the building? Will the roof withstand weather extremes expected at the building site? Can the fire alarm be heard throughout the building? Those broader concerns are the essence of validation. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 64
  65. 65. Discussion - Verification In the initial stages of design, verification is a key quality assurance technique. As the design effort progresses, verification activities become progressively more comprehensive. For example, heat or cooling delivery can be calculated and verified by the air conditioning designer, but the resultant air temperature can only be estimated. Occupant comfort is a function not only of delivered air temperature, but also humidity, heat radiation to or from nearby thermal masses, heat gain or loss through adjacent windows, etc. During the latter design phases, the interaction of these complex factors may be considered during verification of the design. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 65
  66. 66. Discussion - Validation Validation follows successful verification, and ensures that each requirement for a particular use is fulfilled. Validation of user needs is possible only after the building is built. The air conditioning and fire alarm performance may be validated by testing and inspection, while the strength of the roof will probably be validated by some sort of analysis linked to building codes which are accepted as meeting the needs of the user-subject to possible confirmation during a subsequent severe storm. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 66
  67. 67. Verification Testing Examples Following are a few examples of verification methods and activities: • Comparative tests with a proven design (side-by-side) • Inspection of attributes • Analytical Testing • Failure modes and effects analysis. • Package integrity tests. • Biocompatibility testing of materials. • Bio-burden testing of products to be sterilized. • Functional Tests after Sterilization For some technologies, verification methods may be highly standardized. In other cases, the manufacturer may choose from a variety of applicable methods. In a few cases, the manufacturer must be creative in devising ways to verify a particular aspect of a design. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 67
  68. 68. Design Validation Validation should also address product packaging and labeling. These components of the design may have significant human factors implications, and may affect product performance in unexpected ways. For example, packaging materials have been known to cause electrostatic discharge (ESD) failures in electronic devices. If the unit under test is delivered to the test site in the test engineer's briefcase, the packaging problem may not become evident until after release to market. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 68
  69. 69. Documentation – Validation VALIDATION DOCUMENTATION. Validation is a compilation of the results of all validation activities. For a complex design, the detailed results may be contained in a variety of separate documents and summarized in a validation report. Supporting information should be explicitly referenced in the validation report and either included as an appendix or available in the design history file. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 69
  70. 70. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 70 Substantive Evidence to support labeling and claims During verification, the complete device is exercised such that all labeling, displays, and outputs are generated, reviewed, and the results documented. During the verification, all displayed prompts and instructions are checked versus the manufacturer's and FDA's labeling requirements and versus the Instructions for Use (IFU).
  71. 71. Design Transfer ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 71
  72. 72. ©MPI, LLC 2016 all rights reserved. MidWest Process Innovation, LLC Design Controls Begin Concept & Feasibility Risk Analysis Begins Manufacturing Scale-up Design Review Design Review Design Review Design Pilot Mfring. Phase Product And Process Release Inputs Inputs Inputs Transfer Design Changes Begin Design History File Sales and Distribution Product History Outputs OutputsOutputs Design Controls Device Master Record Device History Record Design History File Verification Quality Review Board Design Validation Planning
  73. 73. Discussion – Transfer Foundations – 21 CFR, Part 820.181 Production specifications must ensure that manufactured devices are repeatedly and reliably produced within product and process capabilities. If a manufactured device deviates outside those capabilities, performance may be compromised. Thus, the process of encapsulating knowledge about the device into production specifications is critical to device quality. The level of detail necessary to accomplish this objective varies widely, based on the type of device, the relationship between the design and manufacturing organizations, and the knowledge, experience, and skills of production workers. In some cases, devices are produced by contract manufacturers who have no involvement in the development and little or no contact with the designers. At the other extreme, some devices are hand-crafted by skilled artisans with extensive knowledge about the use of the product. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 73
  74. 74. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 74 During successful Output…..DMR…..What is included? A significant part of the transfer requirement is met when the design output is being created. That is, some of the design output documents are part of the DMR and are used directly for production. The remaining DMR documents are based on design output information. A procedure is needed to cover the generation of the remaining device master record documents based on information in the design output documents.
  75. 75. Design History File (DHF) ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 75
  76. 76. ©MPI, LLC 2016 all rights reserved. MidWest Process Innovation, LLC Design Controls Begin Concept & Feasibility Risk Analysis Begins Manufacturing Scale-up Design Review Design Review Design Review Design Pilot Mfring. Phase Product And Process Release Inputs Inputs Inputs Transfer Design Changes Begin Design History File Sales and Distribution Product History Outputs OutputsOutputs Design Controls Device Master Record Device History Record Design History File Verification Quality Review Board Design Validation Planning
  77. 77. Definitions 820.30(j) Design history file.  Each manufacturer shall establish and maintain a DHF for each type of device.  The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part. 820.3(e) Design history file (DHF) means a compilation of records which describes the design history of a finished device. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 77
  78. 78. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 78 DHF…..start early…..basis for DMR The DHF covers the design activities used to develop the device, accessories, major components, labeling, packaging and production processes.
  79. 79. Discussion Virtually every section of the design control requirements specifies information which should be recorded. The compilation of these records is sometimes referred to as the design history file. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 79
  80. 80. A Tool for Investigations …..the manufacturer lacked design information necessary to validate a design and maintain it throughout the product life cycle. This occurs for the most innocent of reasons-contracts expire, companies reorganize, employees move on to new projects or new jobs. Even when the designer is available, he or she may forget why a particular decision was made years, months, or even weeks before. Since design decisions often directly affect the well-being of device users and patients, it is to the manufacturer's benefit to maintain the knowledge base which forms a basis for the product design and further investigation. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 80
  81. 81. ©Copyright, 2016, MPI, LLC www.midwestprocessinnovation.com 81 DHF Content (examples) Typical documents that may be in, or referenced in, a DHF are listed below: -design plans; -design review meeting information; -sketches; -drawings; -procedures; -photos; -engineering notebooks; -component qualification information; -biocompatibility (verification) protocols and data; -design review notes; -verification protocols and data for evaluating prototypes; -validation protocols and data for initial finished devices; -contractor / consultants information; -parts of design output/DMR documents that show plans were followed; and -parts of design output/DMR documents that show specifications were met.
  82. 82. ©MPI, LLC 2016 all rights reserved. MidWest Process Innovation, LLC Design Controls Begin Concept & Feasibility Risk Analysis Begins Manufacturing Scale-up Design Review Design Review Design Review Design Pilot Mfring. Phase Product And Process Release Inputs Inputs Inputs Transfer Design Changes Begin Design History File Sales and Distribution Product History Outputs OutputsOutputs Design Controls Device Master Record Device History Record Design History File Verification Quality Review Board Design Validation Planning

×