Combination Products Verification, Validation & Human Factors Sept. 12, 2017
Speaker Scott Thiel Director, Navigant Consulting Regulatory consulting in Life Sciences industry with focus on medical devices, software as a medical device, and combination products 30 years of experience in regulated industry; roughly half that time in regulatory roles 2
Objectives Definitions of Verification and validation Human factors and usability Formative and summative usability testing What FDA expects a manufacturer to know regarding these definitions How digital health, software development, cybersecurity, data privacy, and usability interplay in some combination devices 3
Part of a larger picture You are here Quality System 820.5 Scope 820.1 Definitions 820.3 Personnel 820.25 Document Controls 820.40 General (a) Design & Development Planning (b) Design Input (c) Design Transfer (h) Quality Audit 820.22 DMR 820.181 Purchasing Controls 820.50 Receiving, inprocess, & finished device acceptance 820.80 Acceptance Status 820.86 Product Traceability 820.65 Nonconforming Product 820.90 Device Labeling 820.120 Labeling Part 801 UDI CAPA (820.100) Records 820.180 QS Record 820.186 Statistical Techniques 820.250 Design Changes (i) Design Verification (f) Design Review (e) Design Validation (g) Design History File (DHF) (j) Inspection, Measuring & Test Equipment 820.72 DHR 820.184 Process Validation 820.75 Device Packaging 820.130 Storage 820.150 Handling 820.140 Distribution 820.160 Identification 820.60 Installation 820.170 Complaints 820.198 Servicing 820.200 Medical Device Tracking Part 821 Corrections / Removals Part 806 Medical Device Reporting Part 803 Risk Management - Foundational 4
Definitions 5
Verification 21 CFR Part 820.3(aa) Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled Did I make it right? 6
Validation 21 CFR Part 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. (1) Process validation means establishing by objective evidence that a process consistently produces a result or product meeting its predetermined specifications. (2) Design validation means establishing by objective evidence that device specifications conform with user needs and intended use(s). Did I make the right thing? Can I keep making the right thing? 7
Human Factors Human Factors is the application of knowledge about human capabilities (physical, sensory, emotional, and intellectual) and limitations to the design and development of tools, devices, systems, environments, and organizations (ANSI/AAMI HE75:2009, Introduction) 8
Usability Usability: Characteristic of the USER INTERFACE that establishes EFFECTIVENESS, EFFICIENCY, ease of USER learning and USER satisfaction (ISO/IEC 62366:2007, Definition 3.17) 9
Formative evaluation Formative evaluation is the process of assessing, at one or more stages during the device development process, a user interface or user interactions with the user interface to identify the interface s strengths and weaknesses and to identify potential use errors that would or could result in harm to the patient or user (Applying Human Factors and Usability Engineering to Medical Devices Guidance for Industry and Food and Drug Administration Staff) 10
Summative evaluation Summative evaluation is evaluation conducted to demonstrate that the device can be used by the intended users without serious use errors or problems, for the intended uses and under the expected use conditions. The testing should be comprehensive in scope, adequately sensitive to capture use errors caused by the design of the user interface, and should be performed such that the results can be generalized to actual use FDA considers human factors validation a more comprehensive phrase Applying Human Factors and Usability Engineering to Medical Devices - Guidance for Industry and Food and Drug Administration Staff 11
Why usability is important 12
What FDA expects 13
In order to test Requirements and design specifications must be: Known Documented Testable / measurable Traceable Risks understood 14
Known What is the intended use? Who are the intended users? What are the indications for use? What drug/biologic needs to be considered? What is the intended use environment? Where will the product be marketed (i.e. what countries)? How will users interact with the product? What will users do with the information provided? 15
Documented When did formal design control begin? Does a Master File need to be considered for referencing? Were document and record control procedures followed? How will changes be managed? What suppliers are relied upon to generate records? Who needs to or will read the requirements and design specification documents, and for what purpose? Is the information in English? 16
Testable / Measurable Can the requirement or specification be confirmed through testing? What type of testing is needed? Can multiple aspects be tested in one study? Can risk of failing a test be mitigated? What statistical assessments will be used? What are the acceptance criteria? Are the product requirements manufacturable? Are tolerance stack-up concerns considered? 17
Traceable Are requirements documented in a manner that supports tracing from requirements to test results? How will traceability be maintained during development (e.g., design changes)? Who needs to be involved to ensure traceability (e.g., suppliers)? What systems will be used to capture and trace? Can the information be provided in a report usable by FDA reviewers? 18
Risks Understood When was initial risk assessment started? ( Early is a good answer here) Who is involved in the risk assessment? How are product design vs usability risks handled? How are risk assessment items tied into requirements and traceability? Can a product filing benefit from use of a safety assurance case report? (AAMI TIR38) a structured argument, supported by a body of valid scientific evidence that provides an organized case that the infusion pump adequately addresses hazards associated with its intended use within its environment of use. - Infusion Pumps Total Product Life Cycle - Guidance for Industry and FDA Staff 19
New Considerations 20
Software Development rate and methods Risk management Human factors becomes even more important (as though it weren t important enough already) Need to consider a different way of looking at risk plan to spend time CDRH and CDER Enforcement discretion Supplier management 21
Cybersecurity & Data Privacy Design expectations FDA guidance on cybersecurity submissions and postmarket China FDA cybersecurity expectations HIPAA Privacy and security by design and by default GDPR Right to be forgotten More for risk assessment (NIST) 22
Other Considerations Suppliers Using consumer electronics as components Lightly or not regulated used in regulated product Interoperable medical devices Move towards use of interoperability for communication interfaces (IEEE 11073 family; UL 2800 [under development]) Could drive more use of Master Files 23
Roundtable Discussions 24
Questions What are the top 2-3 challenges you have at your organization (may or may not have been mentioned)? 25
Questions What are some possible solutions for the top 2-3 problems identified? 26
Questions For product in development, what areas might need to be reverse engineered to create necessary records? 27
Questions How might we manage rate of change differences between pharma, device, software and consumer electronics? 28