2 Main thrust of the QSR (Quality System Regulation) FDA Mission: Safe and Effective Medical Devices Medical Device Manufacturing must be conducted in a STATE OF CONTROL. Control may be achieved by having WRITTEN procedures, and by TRAINING, usually BOTH. Control requires monitoring of compliance to procedures, AUDITING.
3 Design Controls: Seminar Objectives- Provide a working understanding of FDA requirements for design controls. Instill the skills to devise and implement an FDA compliant design control system in your company. Provide tools which will result in safer product designs and smoother regulatory submissions processes.
4 Today s topics: Introduction - Historical.. Requirements Overview.. Design and Development Planning Design Input Design Reviews Design Output Design History File
5 Historical Perspective MEDICAL DEVICE AMENDMENTS passed to ensure safety and effectiveness of medical devices. The amendments require manufacturers to register with FDA and follow quality control procedures CFR 820- GMP Regulation for Medical Devices Added GAO review of device recalls shows 44% of device problems due to design deficiencies FDA s Preproduction Quality Assurance Planning document outlines design controls recommendations.
6 Historical Perspective, cont SAFE MEDICAL DEVICES ACT of 1990 gives the FDA the authority to establish design validation (I.e.. design controls) GMP draft revision published in Federal Register GMP final rule published in Federal Register June, GMP final rule becomes effective. FDA will audit design controls but will not enforce. No 483 observations for design controls. June, ENFORCEMENT OF DESIGN CONTROLS BEGINS!
7 Part 820 is not rocket science. It is written in plain English that all of you can understand.
8 Terminology: Acronym Alert! (1) GMP: Good Manufacturing Practices. DMR: Device Master Record: means a compilation of records containing the procedures and specifications for a finished device. DHR: Device History Record means a compilation of records containing the production history of a (particular) finished device. DHF: Device History File means a compilation of records which describes the design history of a finished device.
9 Terminology: Acronym Alert! (2) FMEA: Failure Modes and Effects Analysis, an inductive bottom up analysis technique. FMECA: Failure Modes, Effects, and Criticality Analysis includes a risk ranking to the above (probability and severity) FTA: Fault tree analysis, a top down deductive approach to failure mode analysis. ISO: International Organization for Standards is a worldwide federation of national standards bodies. They prepare international standards through technical committees. PEMS: Programmable Electrical Medical Systems
10 Terminology: Acronym Alert! (3) ISO-9001: Quality Systems - Model for Quality Assurance in Design, Development, Production, Installation, and Servicing. Revised in 1994 and now an American National Standard. (Other standards in this series do not include design & development.) This standard was used as a model for FDA s revision of the GMP regulation. SMDA: Safe Medical Device Act of 1990 BOM: Bill of Material. List of component parts of a device or subassembly. ESD: Electrostatic Discharge EMI: Electromagnetic Interference
11 Terminology: Labeling: To the FDA, means device labels, user manuals, advertising, any printed matter re the device. Murphy s Law: Anything that can go wrong, will, and at the worst possible time. Establish means define, document (in writing or electronically), and implement.
12 Why institute design controls?
13 Design Controls: Requirements Overview Throughout the GMP, the terms establish and maintain and designated individual(s) appear. What do these terms this mean? Establish means: Define, document (in writing or electronically), and implement. Maintain means: (1.) Distribute the documents to the appropriate people (2) Train people in their use and (3) Keep them up to date. See document control section of the GMP for other requirements. Designated individuals means people who are qualified to perform the task assigned and are expressly given the authority and responsibility company management. (Org. Chart)
14 Comparison of ISO-9001 to 21CFR (Design Controls) ISO Design Control Design Controls General (a) General Design and development planning. (b) Design and development planning Organizational and technical interfaces Design input (c) Design input Design output (d) Design output Design review (e) Design review Design verification (f) Design verification Design validation (g) Design validation. (h) Design transfer Design changes (i) Design changes Quality records (j) Design history file.
15 Design Controls: Requirements Overview: 21 CFR (a) General: Need written procedures to control the design of the device so that design requirements are met. Applies to all Class II & III devices, and class I devices with software. (b) Design & Development planning. Written plans describing the activities and responsibilities. Describe group interfaces.
16 Design Controls: Requirements Overview: 21 CFR (c) Design input. Procedures to insure design requirements are appropriate. Written device design requirements. (d) Design output. Procedures for defining/documenting design output to assure conformance with input requirements.
17 Design Controls: Requirements Overview: 21 CFR (e) Design review. Procedures to conduct design reviews. Representatives of all functions concerned.. (f) Design verification. Procedures for verifying device design. Confirm design meets input requirements. Written and approved results for DHF.
18 Design Controls: Requirements Overview: 21 CFR (g) Design validation. Procedures for validation of design. Actual or simulated use tests. Software validation. Risk analysis. Documented results for the DHF. (h) Design transfer. Procedures to ensure creation of proper production specifications.
19 Design Controls: Requirements Overview: 21 CFR (i) Design changes. Change control procedure required. Written approval required for changes prior to implementation. (j) Design history file. Records to show device developed in accordance with design plan
20 Verification Vs. Validation.. Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. Validation means confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled.
21 Summary: Requirements for Documentation of Design Controls 1. Device design control procedure(s) (Product development protocol) 2. Specific Device development activity plan with defined responsibilities for implementation and description of interfaces. A living document which evolves and gets reviewed and approved. Goes into DHF for this device. 3. Design input procedures to ensure that design requirements are appropriate. 4. Design input requirements document for specific device.
22 Summary: Requirements for Documentation of Design Controls 5. Procedures for defining design output. 6. Actual design output (approved, signed, and dated)per procedure above. Allows evaluation of conformance to design input requirements (to DHF) The total finished design output consists of the device, its packaging and labeling, and the device master record. 7. Procedures for design reviews. 8. Actual results of design reviews (to DHF) 9. Procedures for design verification. 10. The results of design verification (to DHF)
23 Summary: Requirements for Documentation of Design Controls 11. Procedures for design validation. 12. The results of design validation (to DHF) 13. Procedures for design transfer. 14. Procedures for change control. 15. A DHF, design history file, contains or references records to demonstrate the design was developed in accordance with approved design plan.
24 Design and Development Planning There were 8 generic procedures required. All except one (change control) could be incorporated into a Product Development Protocol. (or Development SOP) In the alternative, Design review and Transfer to production could have their own procedures.
25 A word about procedures... Keep them simple, short and to the point, or they will not be followed. Failure to follow own procedures may result in a 483 observation Train employees in use of the procedures.
26 Product Development Protocol: Areas which need to be addressed Risk analysis Design Input Design Output Design Review Design Verification Design Validation Design Transfer Design Changes (within development) Interfaces (inter- departmental)
27 Design Input Design specifications should be established before any significant design activity begins. We will call design specifications the Product Requirements Document. Number each requirement with a unique designator. This will help us later on during verification/validation.
28 Product Requirements Document This document shall be approved by designated individuals, such as: Marketing Engineering Regulatory/Quality Manufacturing Management Purchasing
29 Product Requirements Document should address: Identity of product Performance characteristics Classification Physical characteristics Environmental characteristics Major components Safety & performance considerations
30 Product Requirements Document sources of information: Competitive products Focus groups of potential users FDA guidance documents which give 510(k) or other product requirements Trade shows Catalogs
31 Product Requirements Document It s a living document which evolves as the product is being developed. Keep previous editions for the DHF. Number each paragraph or significant requirement. Class exercise: create a product requirements document for hypothetical product. (Will be used later..)
32 Project Development Plan Project tasks phases are identified (Pert or Gantt chart) Project tasks are assigned to designated individuals Timelines and cost targets may be included. Requires approvals Keep up to date and keep old versions for DHF.
33 Human Factors Many device problems have been found to be a result of poor understanding of human factors. Patient deaths have occurred as a result. Example: unprotected electrodes Problems: Device use errors - improper hook ups, improper device settings Solutions: Ergonomic or Human factors engineering - See Do it by Design and AAMI Human Factors Engineering Guidelines.
34 Design Reviews 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. Reviews should occur at pre-planned check points during design progress and can also be called for ad-hoc problem solving.
35 Design reviews Minutes of design reviews should be recorded and include: moderator and attendees, date and design phase/stage plans and/or agenda, problems and/or issues to identify and solve minutes and reports, and follow-up report(s) of solutions and/or the next review covers the solutions and remaining issues Minutes are kept in the DHF.
36 Design Output 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. Device master record (DMR) means a compilation of records containing the procedures and specifications for a finished device.
37 Design output requirements Ability to determine conformance to product requirements specification. Acceptance criteria Written, reviewed, and approved prior to release to production. What about partial releases?
38 Design History File: Contents, creation, management. Required by (j) Proof that product was developed according to plan and requirements. Important: needed for regulatory submissions! 510(k), PMA. Documents are never created just to go into the DHF
39 Design history file: contents All versions of product requirements documents. All versions of Development plans (Pert, Gantt, etc..) Minutes and other documentation of design reviews. Verification and validation plans and results. Preliminary design drawings, schematics, software, and the like.
40 Design history file contents, continued Test reports such as EMI, ESD, electrical safety, radiation leakage, and the like. Records of team meetings Significant engineering documents Annotated copies of verified labeling, printouts, etc.. and associated notes and any checklists After device release, any significant changes, including associated validation. Engineers log books or an index of where to find them.
41 Log books: Best to use bound books with numbered pages; write in ink; sign & date every page. Helps substantiate patent claims. Create an index to Engineers log books, serialize them.
42 Design history file: creation, management. (Documents are not created just for DHF) Creation refers to the need to index and track required documents, and assure creation for fulfilling the project plan. Management of the file should be an assigned task. Indexing (ie noting the location) and making copies to assure file completeness is needed.
43 Recap: History Terminology Overview Design & Development Planning Design Input Design Reviews Design Output Design History File
44 What is meant by this?
45 Recap of Today s Topics Introduction - Historical.. Why design controls? Requirements Overview.. Design and Development Planning Design Input Design Reviews Design Output Design History File
46 Today s topics: Design Verification and Validation Design Transfer Change Control Tools for Assuring Device Safety FMEA 510(k)
47 Design Verification and Validation Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. Design output meets design input requirements. Verification Validation means confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled. Design conforms to user needs and intended uses. Done on initial production units under simulated or actual use conditions. Validation
48 Design Verification Most important point: A requirements traceability matrix to ensure test coverage of all product requirements. Using the product requirements document we previously created, generate a requirements traceability matrix for our verification project phase. Verification shall show that results meet requirements. Store in DHF.
49 Design Validation (Distinguish from Process Validation) Validation procedures must be written. Performed under defined operating conditions and simulated or actual use conditions, on initial production units, lots, batches, etc. Includes software validation and risk analysis. Tests designed to stress the limits..
51 Design Transfer (to Manufacturing) Subsections may be transferred before entire design is complete. Production specifications are what is transferred. They constitute the DMR These include: BOM s, schematics, assembly drawings, assembly instructions.
52 Change Control It is usually appropriate to have a separate written change control procedure. Once a design is transferred to production, change control must be used. A separate change control procedure (perhaps less formal) may be used prior to transfer.
53 Change control: key points - Validation and/or verification of the change required prior to implementation Review and approval required. Sec addresses document changes. Since the DMR consists mainly of documents, this rule applies. Beware of sneak DMR changes. Very common problem: Unapproved DMR documents.
54 Tools for assuring device safety- Risk or Hazard Analysis Tools. Risk Analysis called for in Product Development Protocol per FDA s Inspectional Strategy Preproduction Quality Assurance Planning and is often required in 510(k) submissions. Performing Risk Analysis is a defense to product liability suit.
55 Other Safety tools: Adherence to Safety Standards IEC 601-1, Medical Electrical Equipment Part 1: General Requirements for Safety IEC 513, Fundamental aspects of safety standards for medical electrical equipment IEC , Safety Requirements for Programmable Electronic Medical Systems IEC 825, Procedures for failure modes and effects analysis IEC 1025, Fault Tree Analysis IEC EN 1441, Medical Devices - Risk Analysis UL Safety Standards AAMI Standards US Govt. Performance Standards 21CFR10xx.
56 General Risk or Hazard Analysis Tools Fault Tree Analysis (top down analysis) FMEA and FMECA: Failure Modes and Effects Analysis, Failure Modes Effects and Criticality Analysis. (bottom up analysis) FMECA includes criticality analysis, or level of severity and probability of failure. MIL-STD-1629
57 Issues to consider: Human Error: Manufacturing operation, Operator, Home User, Service Person Software Error Electronic Component Failure Mechanical Component Failure Normal wear-out Murphy s Law
58 Hazard Analysis Process Identify Hazards via formal process (FTA and/or FMEA) Evaluate (probability and severity) and define mitigation Implement and verify mitigation Review in light of complaint files and repair records.
59 Fault Tree Analysis (top down, deductive) 1. List the possible hazards, such as: Fire, electrical shock, mis-diagnosis, injury, etc. 2. What failures, or combination of failures, will lead to the named hazards? 3. Diagram the fault tree. 4. Use the tool to intercept or design out unacceptable consequences.
60 Fault Tree Analysis: symbols Result or Event "AND" gate "OR" gate
61 FMEA: Failure Mode and Effects Analysis A bottom up, inductive approach. System FMEA Vs Design FMEA. Design FMEA looks at product as a unit and examines failure potentials at the core levels of a device. Examine each component and its failure mechanism. For software and hardware A systematic data sheet approach is employed
62 FMEA Function or Component Failure Mode Effect on System Possible Hazards Risk Index User Detection Means Applicable Control
63 Risk Index Table Probability of Occurrence Severity I Catastrophic (Death, serious injury) Severity II Significant (Reversible serious injury) Severity III Marginal (Inconvenience) Severity IV Negligible Frequent Probable Occasional Remote Improbable
64 Safety testing
65 Safety Testing Overview: Electrical safety Applicable standards: UL-544 (Being replaced by UL-2601= IEC-601, AAMI SCL (Safe Current Limits) IEC Medical electrical equipment - General requirements for safety Tests covered - Prevention against electrical shock: Ground resistance Chassis leakage High-voltage breakdown Patient connection leakage - sink and source Why?
66 Safety Testing Overview: Other sections in IEC-601: Identification & marking requirements Environmental - operating and storage Mechanical hazards Excess radiation Flammable anesthetics Excessive temperatures and other hazards; ESD, fire, leakage, pressure, human error Accuracy of operating data and protection against hazardous output Fault conditions Constructional requirements
67 Safety Testing Overview: EMI per FDA recommendation EMC radiated and conducted according to CISPR 11 Magnetic low frequency emissions per RE101, MIL- STD-462D (if concerned about health effects..) ESD per IEC /- 8KV Air, +/- 6KV Contact AC voltage fluctuations, transients, and surges See tabs 13, 14, and 15. Why?...
68 Safety testing: The FDA has numerous documents available via Facts-On-Demand Fax back service, These documents give details, in many cases, on what safety and effectiveness testing the FDA expects to see in submissions.
69 510(k): Getting the device to market Many of the documents generated under design controls will be needed for the 510(k) - A pre-market notification required for most devices. Device classes - Three general categories with increasing regulatory requirements necessary to assure safety and effectiveness..
70 510(k): Getting the device to market - submission components- General Information - Identification Proposed labeling, labels, advertisements, users manuals Intended uses Comparison to legally marketed device Diagrams, engineering drawings, photographs more...
71 510(k): Getting the device to market - submission components- Performance data: bench, animal, clinical (from verification and validation!) Software validation and verification. Biocompatibility & Sterility Information Conformance to standards certifications such as UL, IEC, others. The information in the DHF and DMR feeds directly into the 510(k) submission
72 Recap.. Design verification and validation Design transfer Change control Tools for assuring device safety - FMEA, etc. Safety testing The 510(k)
73 Today s topics: Software validation Process validation Wrap-up and open discussion
74 Software validation This topic has attracted the attention of the FDA because of problems which have led to patient deaths, among other reasons. Case in point: The Therac-25 11/13/89: FDA s Draft Policy for regulation of computer products (medical devices)
75 Software validation 1990: Application of Medical Device GMPs to computerized devices and manufacturing processes. 1991: Reviewer Guidance for Computer Controlled Medical Devices Undergoing 510(k) review. 1996: ODE Guidance for Medical Devices Containing Software (Draft) Relies on IEC
76 Software validation IEC Medical electrical equipment Part 1: General Requirements for Safety 4. Collateral Standard: Programmable electrical medical systems (PEMS) Useful section of Draft Guidance: Appendix C. Review Checklist and Common Requests (of 510(k) reviewers)
77 Software validation: Concepts - System Development Life Cycle Initiation phase Requirements analysis phase Design phase Programming and testing phase Integration and system test phase Validation phase Operations and maintenance phase Retirement phase
78 Software emphasis: Risk Management ODE Guidance: sec. 2.1: Distinct phases for work Feedback among phases V & V activities look for sources of error Development lifecycle and risk management fully integrated. See ODE guidance fig. 2-1 Again, level of concern fig. 3-1
79 FDA s expectation: Appendix C - Review Checklist Hazard Analysis Safety incorporated Appropriate methodology Verification and Validation prior to release? Traceability? (to requirements) Change control Other - hazardous functions limited only by software (Therac-25!)
80 Vendor supplied software Needs to be qualified by company. Amount of qualification varies. Need version control of vendor supplied software. Applies to vendor supplied firmware as well: BIOS for example. Attempt to obtain assurance that vendor used a quality process in development Once validated, carefully control the version
81 Software checklists Software GMP Questions Software Assessment Questionnaire (possible model for internal audit) Software questions for 510(k) submissions IEEE Std ; Std
82 Process validation: IQ, OQ, PQ. Typical application: Manufacturing process which is not 100% inspected, such as wave soldering. IQ means Installation Qualification. Was machine installed according to manufacturers requirements? Establish maintenance and calibration requirements. Secure manuals. Write work instructions.
83 Process validation: IQ, OQ, PQ. OQ means Operational Qualification. The machine is operated. Does it perform according to manufacturers claims? PQ means Process Qualification. The machine is tested with your product with an eye to stressing the limits of the process : high/low temperature, high/low conveyer rate, etc. Can the manufacturing process consistently produce product meeting requirements?
84 Open discussion. Sources for additional help FDA s World Wide Web Site: ASQC IEC standards
An Introduction to Risk/Hazard Analysis for Medical Devices By Daniel Kamm, P.E., C.Q.A. Rev May 6, 2005 Risk analysis, or hazard analysis, is a structured tool for the evaluation of potential problems
GMP How to Develop an Effective Design Control Program: A Life-Cycle Multi-Phase Approach Jackelyn Rodriguez This article provides a life-cycle methodology in a multi-phase approach that includes an effective
environmental failure analysis & prevention health technology development How to Use the Design Process to Manage Risk: Elements of Design Controls and Why It Matters Kevin L. Ong, Ph.D., P.E. Managing
IVD Regulation Overview Requirements to Assure Quality & Effectiveness CLIAC Jan. 2002 Statutory and Regulatory Requirements Statute: Food, Drug, and Cosmetic Act Food and Drugs Act of 1906 Food and Drug
Risk Assessment for Medical Devices Linda Braddon, Ph.D. Bring your medical device to market faster 1 My Perspective Work with start up medical device companies Goal: Making great ideas into profitable
Introduction into IEC 62304 Software life cycle for medical devices Christoph Gerber 4. September 2008 SPIQ 9/5/2008 1 Agenda Current Picture Regulatory requirements for medical device software IEC 62304
Overview: The FDA requires medical device companies to verify that all the design outputs meet the design inputs. The FDA also requires that the final medical device must be validated to the user needs.
Corrective and Preventive Action Background & Examples Presented by: Kimberly Lewandowski-Walker Food and Drug Administration Division of Domestic Field Investigations Office of Regulatory Affairs Overview
Quality System: Design Control Procedure - Appendix Page 1 of 10 Quality System: Design Control Procedure - Appendix CORP Medical Products Various details have been removed, indicated by [ ] 1. Overview
WHITEPAPER: SOFTWARE APPS AS MEDICAL DEVICES THE REGULATORY LANDSCAPE White paper produced by Maetrics For more information, please contact global sales +1 610 458 9312 +1 877 623 8742 email@example.com
Section 5: Quality Systems Regulation (QSR) and Good Manufacturing Practice (GMP) 1 Quality Systems Regulation (QSR) 2 Quality Systems Regulation (QSR) and Good Manufacturing Practice (GMP) Sets of checks
Changing Regulatory Requirements for Electronic Medical Devices Dirk Smith Co-Founder Minnetronix Inc. 250 employees, 20 years in business 130+ Class II/Class III device programs in our history 100+ engineers
Choosing the Best Device Sample Size for Verification and Validation Steven Walfish Staff Statistician, Corporate Quality Agenda Validation scope Statistical tools MSA Design Verification and Validation
AAMI TIR 36: Validation of SW for Regulated Processes Denise Stearns April 2008 Agenda Software for Regulated Processes TIR In Scope Discussion Software V&V Basis for TIR The Journey to Critical Thinking
ORACLE CONSULTING GROUP An Official United States Agent Firm for Foreign Establishments CONSULTING MEMORANDUM: DEALING WITH A MEDICAL DEVICE IN THE U.S. 5398 Golder Ranch Rd., Ste. 1 Tucson, Arizona 85739
C O V E R F E A T U R E Coping with Defective Software in Medical Devices Steven R. Rakitin Software Quality Consulting Inc. Embedding defective software in medical devices increases safety risks. Given
INTRODUCTION This book offers a systematic, ten-step approach, from the decision to validate to the assessment of the validation outcome, for validating configurable off-the-shelf (COTS) computer software
STERLINGTECH AND KLOCWORK WHITE PAPER NOVEMBER 2009 Effective Software Verification for Medical Devices Achieving compliance and meeting productivity goals with static analysis In addition to producing
Risk Management: A Regulatory Perspective Timothy A. Ulatowski Director, Office of Compliance, Center for Devices and Radiological Health USA Food and Drug Administration Beijing October 2008 Agenda Part
Page 1 of 7 Home Inspections, Compliance, Enforcement, and Criminal Investigations Compliance Actions and Activities Warning Letters 2014 Inspections, Compliance, Enforcement, and Criminal Investigations
Title: Basic Principles of Risk Management for Medical Device Design WHITE PAPER Author: Ganeshkumar Palanichamy Abstract Medical devices developed for human application are used for diagnostic or treatment
ISO 9000 Quality Standard Background Information www.itilhelp.com There is a worldwide trend towards more stringent customer expectations with regard to quality. Accompanying this trend has been a growing
Specialties Manufacturing Talladega Castings & Machine Co., Inc. ISO 9001:2008 This document is the property of TMS and may not be reproduced, wholly, or in part, without the express consent of TMS. Rev.
Quality & Compliance Associates, LLC Best Practice In A Change Management System President Quality & Compliance Associates, LLC Change Control and Its Role in a Continuous Improvement Environment 3 Benefits
1 of 11 1. Introduction The International Safe Transit Association (ISTA), a non-profit association whose objective is to prevent product damage and excess packaging usage within the distribution environment.
II.2 Life Cycle and Safety Safety Life Cycle: The necessary activities involving safety-related systems, occurring during a period of time that starts at the concept phase of a project and finishes when
Manufacturing Process Qualification & Validation Naren Patel Naren Patel 1 Manufacturing Process Qualification & Validation Tutorial Why to Validate What to Validate Program How to Perform successful Validation
ISO 13485:2016 QUALITY MANAGEMENT SYSTEMS STANDARD Overview Purdue Manufacturing Extension Partnership (800) 877-5182 www.mep.purdue.edu About the Instructor Aaron Ramsey Lead Service Manager of Quality,
Company Name Street Address City, State, Zip code Phone Number Fax Company Website Email Address ORGANIZATION NAME PHONE NUMBER EMAIL ADDRESS President/CEO General Manager Engineering Manager Production
John E. Lincoln] Medical Device Development Under Control John E. Lincoln Device Validation Forum discusses regulatory requirements, scientific principles, strategies, and approaches associated with medical
Far West Technology, Inc. ISO 9001 Quality Manual Document No.: QM Revision: 0 Issue Date: 27 August 1997 Approval Signatures President/CEO Executive Vice President Vice President/CFO Change Record Rev
[ John E. Lincoln Medical Device Product Verification and Validation John E. Lincoln Device Validation Forum discusses regulatory requirements, scientific principles, strategies, and approaches associated
Luminus Devices, Inc Quality Management Systems Manual ISO 9001:2008 This document belongs to Luminus Devices, Inc. It cannot be reproduced without authorized authority. Area: Quality System Document Page
ISO 13485:201x What is in the new standard? Eric Finegan, Quality Mgr, BTE Technologies, Inc. 2015-09-10 1 Presentation Slides This slide deck is the presentation performed on 2015-09-10. A more detailed
Risk Management Applications in Quality Food, Drug, and Cosmetic Division MidWest Conference Presented by: Bruce Haggar Adding Value Period MedQ Systems, Inc. 329 Berner Ave. Hazleton, PA 18201 USA www.medqsystems.com
ISO 9001:2008 Page: 1 of 22 Central Technologies has developed a Quality Management System, and the associated procedures and work instructions, to be compliant to ISO 9001:2008. Utilizing this Quality
FDA Medical Device Industry Coalition ISO 14971: Overview of the standard Risk Management Through Product Life Cycle: An Educational Forum William A. Hyman Department of Biomedical Engineering Texas A&M
Edwin Lindsay Principal Consultant, Tel: + 44 (0) 7917134922 E-Mail: firstname.lastname@example.org There were no guidelines/ regulations There was no training No Procedures No Inspectors Inform All staff of
Page 1 of 20 ISO 9001 (2000) QUALITY MANAGEMENT SYSTEM ASSESSMENT REPORT SUPPLIER/ SUBCONTRACTOR SUPPLIER/ SUBCONTRACTOR NAME: ADDRESS: CITY AND STATE: ZIP CODE: SUPPLIER/MANUFACTURER NO PHONE: DIVISION:
Patient safety in external beam radiotherapy - Guidelines on risk assessment and analysis of adverse events and near misses. Risk management for external beam radiotherapy Recommendations (draft) Jean-Luc
ISO 9001:2008 11 Industry Lane Flippin, Arkansas 72634 QM-001-2008-F Page 2 of 39 Introduction Micro Plastics, Inc. developed and implemented a Quality Management System in order to document the company
Intland s Medical Template Traceability Browser Risk Management & FMEA Medical Wiki Supports compliance with IEC 62304, FDA Title 21 CFR Part 11, ISO 14971, IEC 60601 and more INTLAND codebeamer ALM is
Guidance for Industry and FDA Staff Class II Special Controls Guidance Document: Arrhythmia Detector and Alarm Document issued on: October 28, 2003 The draft of this document was issued on December 13,
Medical Device Software Standards for Safety and Regulatory Compliance Sherman Eagles +1 612-865-0107 email@example.com www.softwarecpr.com Assuring safe software SAFE All hazards have been addressed
2 of 34 Revision Summary Revision Number Date Description of Revisions Initial issue of the document. Table of Contents Item Description Page 1. Introduction and Purpose... 5 2. Project Management Approach...
QUALITY ASSURANCE MANUAL JPM OF MISSISSIPPI, INC. Hattiesburg, MS Revision E 01/19/11 Revised to ISO 9001:2008 on July 9, 2009 JPM OF MISSISSIPPI, INC. MANAGEMENT QUALITY POLICY It is the goal of JPM of
Supplier Quality Standard 1.0 Purpose The purpose of this Supplier Quality Standard is to communicate the expectations and requirements of Baxter Healthcare Corporation to its suppliers. These expectations
GxP Process Management Software : Ten Most Common Reasons for FDA 483 Observations and Warning Letter Citations Most FDA violations involve one of the following: Not having procedures in a regulated area
Reprinted from PHARMACEUTICAL ENGINEERING The Official Magazine of ISPE July/August 2011, Vol. 31 No. 4 www.ispe.org Copyright ISPE 2011 The ISPE GAMP Community of Practice (COP) provides its interpretation
ISCT Cell Therapy Liaison Meeting AABB Headquarters in Bethesda, MD September 10, 2009 David Doleski, Team Leader, Branch 2 Division of Manufacturing and Product Quality (DMPQ) Office of Compliance and
Version 6.0 FSC36 SAFE FEED/SAFE FOOD: Guidance for Developing, Documenting, Implementing, Maintaining and Auditing the Program (Edition 6.0) PREFACE FSC36 SAFE FEED/SAFE FOOD: Guidance for Developing,
General Principles of Software Validation; Final Guidance for Industry and FDA Staff Document issued on: January 11, 2002 This document supersedes the draft document, "General Principles of Software Validation,
General Principles of Software Validation; Final Guidance for Industry and FDA Staff Document issued on: January 11, 2002 This document supersedes the draft document, "General Principles of Software Validation,
Title: Quality Management System Manual Page: 1 of 20 INTRODUCTION Inductors Inc., founded in 1991, specializes in the distribution of inductive components, including but not limited to standard and custom
PERMANENT DOCUMENT CIG 021 Harmonised Requirements UL does not endorse any vendors or products referenced herein. UNDERWRITERS LABORATORIES INC. ASSUMES NO RESPONSIBILITY FOR ANY OMISSIONS OR ERRORS OR
ISO 9001 Quality Systems Manual Revision: D Issue Date: March 10, 2004 Introduction Micro Memory Bank, Inc. developed and implemented a Quality Management System in order to document the company s best
g GE Power & Water ISO 9001:2008 Audit Checklist Organization Auditor Date Page 1 Std. 4.1 General s a. Are processes identified b. Sequence & interaction of processes determined? c. Criteria for operation
Combination Products Presented by: Karen S. Ginsbury For: IFF March 2014 Types of products Biological and medical device (freeze dried + syringe dual volume) Medical device and plasma devised product (syringe)
VERIFICATION PROGRAM FOR A VOLUNTARY HAZARD ANALYSIS CRITICAL CONTROL POINT PLAN (HACCP) ASSOCIATION OF AMERICAN FEED CONTROL OFFICIALS Kent Kitade 6-7-2010 PREAMBLE Hazard Analysis and Critical Control
Lotlikar et al Journal of Drug Delivery & Therapeutics; 2013, 3(2), 149-154 149 Available online at http://jddtonline.info REVIEW ARTICLE QUALITY RISK MANAGEMENT (QRM): A REVIEW Lotlikar MV Head Corporate
Page 1 Company Name: Date of audit: Date of last audit performed: Name of person performing self-audit: Signature: Name of person responsible for quality system: Signature: Number of non-compliances: Page
FDA Perspectives on in Device Development Molly Follette Story, PhD FDA /CDRH / ODE Understanding Regulatory Requirements for Usability Testing RAPS Webinar June 7, 2012 Overview What are human factors
Page 1 of 6 U.S. Food and Drug Administration Protecting and Promoting Your Health Ambco Electronics, A California Corp 9/26/14 Department of Health and Human Services Public Health Service Food and Drug
Page 1 of 5 This document has been created and reviewed by the A2LA Electromagnetic Advisory Committee (EMAC). It provides a summary of consensus decisions voted on and approved by the EMAC and A2LA Criteria
Procedure for Internal Audit Procedure No. 305 Print Name Title Date Prepared by Louise Quality Assurance 09/04/09 Naughton Consultant Reviewed by Niamh Mooney Assistant fire and Safety Officer 09/04/09
Improved Utilization of Self-Inspection Programs within the GMP Environment A Quality Risk Management Approach Barbara Jeroncic Self-inspection is a well-established and vital part of the pharmaceutical
Systems Engineering for FDA QSR Compliance James H. Jones Optants Documented Decision Support Company (ODDSCO) 297 Casitas Bulevar, Los Gatos, CA 95032-1119 www.optants.com firstname.lastname@example.org Copyright
*Changes from the previous QASE noted by "yellow" highlight of block Evaluation Summary Company: Prepared By: Section Element Manual Audit OK Objective Evidence 2.1 Objective of Quality Assurance Program
Process Validation in Radiation Sterilization Dr. Joern Meissner, Meissner Consulting GmbH Munich, Germany Agenda Process Control Process Validation Radiation Sterilization Methods Impact of the updated
Safety Regulation Group SAFETY MANAGEMENT SYSTEMS GUIDANCE TO ORGANISATIONS April 2008 1 Contents 1 Introduction 3 2 Management Systems 2.1 Management Systems Introduction 3 2.2 Quality Management System
THE KOCOUR COMPANY 4800 S. St. Louis Avenue, Chicago, IL 60632 Metal Finishing Instrumentation, Equipment and Supplies ISO 9001: 2008 QUALITY MANAGEMENT MANUAL ISSUED: 03/01/02(REV. 0) REVISION NO: 4 DATE:
Quality Risk Management - The Medical Device Experience Niamh Nolan Principal Design Assurance Engineer Boston Scientific Agenda Intent of Risk Management (RM) and Associated Regulations Overview of RM
TITOLO SLIDE Testo Slide Testo Slide Testo Slide Clinical database/ecrf validation: effective processes and procedures IV BIAS ANNUAL CONGRESS Padova September, 26 th 2012 PQE WORKSHOP: What's new in Computerized