FDA REGULATION OF DIGITAL HEALTH DIGITAL HEALTH LEGAL AND REGULATORY BOOTCAMP WHAT YOU DON T KNOW YOU DON T KNOW
Table of Contents DIGITAL DIGITAL HEALTH LEGAL AND HEALTH REGULATORY LEGAL BOOTCAMP AND WHAT REGULATORY YO DON T KNOW YOU DON T KNOW BOOTCAMP WHAT YOU DON T KNOW YOU DON T KNOW PART 1 REGULATORY STRATEGY SECTION 1.1: SECTION 1.2: SECTION 1.3: SECTION 1.4: Overview of US FDA Regulatory Framework for Medical Devices Regulatory Pathways Post-Market Considerations New Developments & International Considerations PART 2 PRODUCT DEVELOPMENT CONSIDERATIONS SECTION 2.1: SECTION 2.2: SECTION 2.3: SECTION 2.4: Frequently Forgotten Best Practices Quality Management Systems Design & Development Verification & Validation Q&A
DIGITAL HEALTH LEGAL AND REGULATORY BOOTCAMP WHAT YOU DON T KNOW YOU DON T KNOW Part 1: Regulatory Strategy
1.1 Overview of US FDA Medical Device Regulation Risk & Novelty Class III Pacemaker/Defibrillator, Neurostimulators, Artificial Pancreas, Computer-Aided Diagnostic/Therapy Class II Cardiac Monitors, Peripheral Nerve Stimulators, Blood Glucose Meters, Imaging Diagnostic Software Class I Medical Device Data Systems, Wheelchair, Surgical Instruments, Orthotics, Liquid Bandages Regulatory Oversight REGULATORY OVERSIGHT General Controls Special Controls Performance Standards REGULATORY PATHWAYS Registration & Listing Pre-market Notification 510(k) Clearance De Novo Request Pre-market Approval (PMA) Prohibition against adulterated or misbranded devices Premarket notification 510(k) requirements Good Manufacturing Practices (GMPs) Labeling Registration of manufacturing facilities Listing of device types Record keeping Repair, replacement or refund
1.1 Medical Device Regulations Part Covers 11 Electronic Records and Signatures 50 Protection of Human Subjects 1 54 Financial Disclosures by Clinical Investigators 56 Institutional Review Boards 801 Product Labeling 803 Medical Device Reporting 806 Removals and Corrections 807 Registrations & Listings 812 Investigations Device Exemptions 814 Premarket Approvals (PMAs) (for class III devices) 820 Quality System Regulations (includes design controls) 822 Post-market Surveillance 860 Medical Device Classifications All medical device manufacturers must comply with all of the regulations, above 1 Greyed regulations are specific to clinical trials
Part 820 Defines the Requirements for: Management Responsibility (820.20); Quality Audits (820.22); Personnel training and qualification (820.25); Design Control (820.30); Control of documentation (820.40); Purchasing control (820.50); Product identification and traceability at all stages of production (820.60); Controlling and defining production and process (820.70); Defining and controlling inspection, measuring and test equipment (820.72); Product acceptance (820.80 & 820.86); Controlling nonconforming product (820.90); Instituting corrective action and preventive action (CAPA) (820.100); Labeling and packaging controls (820.120 & 820.130); Handling, storage, distribution and installation (820.140, 150, 160 & 170); Control of records (820.180, 181, 184, 186 & 198); Servicing (820.200); Statistical techniques (820.250) Validating processes (820.75);
1.1 Overview Medical Device Regulation Recognized Standards Guidance In addition to the general set of medical device regulations, each device type has a specific regulation that describes the device and establishes the device's classification: Example: Infusion Pumps are governed by regulation 21 CFR 880.5725 Regulation 880.5725 establishes infusion pumps as class II devices
1.2 Regulatory Pathways Digital Health products fall within all device classes depending on intended use Intended use is determined by objective evidence Written or oral statements Device functionality Target market Requirements are defined in statutes, regulations, guidance, and standards
1.2 Regulatory Pathways Stage-Gate Process for the Development of Medical Devices Jan B. Pietzsch, Lauren A. Shluzas, M. Elisabeth Paté-Cornell, Paul G. Yock and John H. Linehan.J. Med. Devices 3(2), 021004 (Jun 17, 2009)
1.3 Post-Market Considerations Post-Approval Studies May be required as part of PMA or De Novo Reclassification May become increasingly important for machine learning algorithms that adapt post-launch Marketing & Advertising Must be truthful and non-misleading Must not result in intended use creep Post-Market Surveillance Must be prepared to maintain the QMS Must be prepared to handle complaints and MDR reporting FDA Inspections Must expect an FDA inspection 2-3 years after first product launch
1.3 Post-Market Considerations FDA Cybersecurity Expectations Impossible to completely mitigate risks through premarket controls alone Cybersecurity Risk Management Emphasize addressing vulnerabilities in a timely fashion Critical components include: Monitoring cybersecurity information sources Maintaining robust software lifecycle processes Understanding, assessing, and detecting presence and impact of a vulnerability or incident Establishing and communicating processes for vulnerability intake and incident handling Deploying methods to analyze, detect, and assess threat sources Using threat modeling to clearly define how to maintain safety and essential performance Adopting a coordinated vulnerability disclosure policy and practice Deploying mitigations that address cybersecurity risk early and prior to exploitation
1.4 Developments & Considerations REGULATION OF MEDICAL AND CERTAIN DECISIONS SUPPORT SOFTWARE. The term device, as defined in section 201(h), shall not include a software function that is intended: Administrative support of a health care facility Maintaining or encouraging a healthy lifestyle Serve as electronic patient records Transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results Unless the function is intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system, for the purpose of: Displaying, analyzing, or printing medical information about a patient, Supporting or providing recommendations to a health care professional, and Enabling such health care professional to independently review the basis for such recommendations. Section 3060 of the 21st Century Cures Act (Public Law 114-255)
1.4 Developments & Considerations FDA s Pre-Cert Program A voluntary program to develop a tailored approach to regulating by focusing primarily on the digital health technology developers rather than the product Goal is to establish a system to evaluate culture of quality and organizational excellence to allow software iterations in a timely fashion Participants include Apple, Fitbit, Samsung, Verily, J&J, and Roche Look for some form of program in place by end of 2018. Use of Real-World Evidence RWE may be suitable to support (or supplement the total evidence required for) the clearance or approval of a new device Real-World Data (RWD) are data relating to patient health status and/or the delivery of health care routinely collected from a variety of sources. Real-World Evidence (RWE) is the clinical evidence regarding the usage, and potential benefits or risks, of a medical product derived from analysis of RWD.
1.4 Developments & Considerations FDA is seeking public feedback on this version of the working model by May 31, 2018 at https://www.regulations.gov/comment?d=fda-2017-n-4301-0001.
1.4 Developments & Considerations
1.4 Developments & Considerations FDA Guidance Implementation of 21 st Century Cures 3060 Changes the definition of a medical device for certain software. Updates across multiple existing guidance documents. MDDS, EHR, and certain CDS are formally no longer under the definition of a medical device. Clinical Decision Support (CDS) Software Outlines how FDA intends to regulate CDS software. Introduces concept of PDS. The vast majority of comments include: Request for additional examples (many ask for more explanation with existing examples) Criteria for or change the requirement for understandable and publicly available and generally accepted clinical practice information regarding what is used by the software and as part of transparency determination. The guidance fails to take a risk-based approach and that intended use is not central to the decision process of regulated vs not. A large number of comments include: Machine learning and artificial intelligence are not considered at all in the document. Unclear how to address multifunctional software (e.g., software with modules where some are regulated and some are not). The guidance goes beyond what is outlined in Cures, though there is general agreement that introducing PDS is a good thing. That the guidance is overly restrictive and does not follow least-burdensome approach.
1.4 Developments & Considerations EU Medical Device Regulation New regulations for medical devices (including software) come into full force in 2020 Changes from MDD to MDR include: New pre-market scrutiny mechanism for high-risk devices Strengthening of post-market surveillance requirements Establishment of a comprehensive EU UDI database Increase focus and enforcement of clinical evidence requirements ISO 13485: 2016 Quality Management System Ability to obtain 3rd Party Certification Supports international marketing plans Can help achieve, but does not guarantee, compliance with FDA quality system regulations FDA considering recognizing the 2016 revision.
Part 2: Product Development Considerations DIGITAL HEALTH LEGAL AND REGULATORY BOOTCAMP WHAT YOU DON T KNOW YOU DON T KNOW
2.1 Frequently Forgotten Best Practices 1. Quality Starts with a Quality Management System Early establishment of a QMS and compliance with QMS policies & procedures are critical 2. Carefully Research, Define, and Document Requirements What are the operator requirements? Safety requirements? Patient requirements? Requirements driven by user needs 3. Consider Hazards/Risks and Incorporate into Requirements Functionalities that prevent or mitigate known hazards should be added to the list of requirements and tested appropriately 4. Establish and Follow Change Control Procedures Changes to design require careful consideration and approval from a broad group of stakeholders 5. Traceability is Crucial The ability to trace from requirements through risk management to testing output, while maintaining change control, is critical.
2.1 Frequently Forgotten Best Practices 6. Maintain a Revision History Retrospectively re-constructing the software revision history is difficult and painful Maintain a revision history that describes changes and reason(s) for making them 7. Adequately Define and Document V&V Activities Test cases including acceptance criteria, results, and pass/fail disposition must always be documented (i.e., If it isn t documented, it didn t happen! ) Testing prior to plan approval is forbidden and will result in re-testing 8. Consider Future Versions of the Device and Associated Functionalities If possible, write code in a modular fashion to reduce V&V burden for additional functionalities and/or claims extensions Regulatory clearance/approval for new functionality/claims will only require a simple license to implement the functionality on units already on the market
2.2 Quality Management System Quality Management System Manufacturers must establish and follow policies and processes for relevant aspects of the QMS Design Controls, Document Controls, Process Controls, and CAPA are common FDA audit observations Management are subject to personal civil and criminal liability for violations under the Park doctrine
2.2 Design Control General (a) Design & Development Planning (b) Design Input (c) Design Transfer (h) Design Verification (f) Design Validation (g) Design Changes (i) Design Review (e) Design History File (DHF) (j)
2.3 Design & Development Design Concept Tech Development Plan (SW Quality Assurance Plan) Technology Specification (SW Req. Spec.) Technology Development Process General Overview Risk Management Plan (Hazard Analysis/Fault Tree) Development (SW Coding) Design V&V Product Release
2.3 Design & Development How FDA approaches Design Records: 1. Product description and intended use Product requirements 2. Traceability Matrix 3. Risk management file Mechanical Design Specifications Mechanical verification Intended use Intended users Intended use environment Product Requirements Electrical Design Specifications Electrical verification System Design Verification System Design Validation Summative Usability Business requirements Software Design Specifications Unit Verification Integration Verification Formative Usability Testing Risk management
2.3 Product Requirement Example
2.3 Product Requirement Example
2.3 Product Requirement Example
2.3 Design Specification Example
2.3 Design Specification Example
2.3 Risk Estimation & Evaluation Item # Hazard Type Potential Failure Mode Description Potential Harm Severity Potential Cause of Failure (Trigger Event) Occurrence Risk Risk Control Measure(s) Post- Mitigation Occ Risk Hazards Related to the Use of the Device HA 01 Results Error Erroneous results (high or low) Intervention to move user result in the wrong direction Ambient light causes user to misread display HA 02 Results Error Erroneous results (high or low) Intervention to move user result in the wrong direction Bias in recovered memory value HA 03 Results Error Result not produced Confused user, Customer irritation Result misidentified as control solution, therefore different coefficients will be used. Value not available for calculation or trending. Due to the use of the different coefficients, the result produced will be biased when compared to the result produced if the sample had been appropriately identified.
2.3 Verification & Validation Definitions Verification = confirmation by examination and provision of objective evidence that specified requirements have been fulfilled Validation = establishing by objective evidence that device specifications conform with user needs and intended use(s) Verification & Validation Models Static vs. Dynamic Analysis (i.e., product/process reviews vs. beta testing) Product Audits V&V Task Iteration Test Planning & Design What will be tested? How? What are the acceptance criteria?
2.3 Verification & Validation Code Reviews, Inspection, Module Testing, Integration Testing Formal or Informal System or Functional Design Reviews Documenting and reviewing test results is critical
2.4 Verification Protocol Example
2.4 Verification Protocol Example
2.4 Unit & Integration Output
2.4 Verification Output
2.4 Trace Matrix Examples
2.4 Trace Matrix Examples
2.4 Usability Why is it important?
2.4 Usability Definitions Formative Usability Evaluation 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. Human-Factors Validation (aka Summative Usability) Testing conducted at the end of the device development process to assess user interactions with a device user interface to identify use errors that would or could result in serious harm to the patient or user. Human factors validation testing is also used to assess the effectiveness of risk management measures. Human factors validation testing represents one portion of design validation.
2.4 Summative Usability Examples
2.4 How it fits together Mechanical Design Specifications Mechanical verification Intended use Intended users Intended use environment Product Requirements Electrical Design Specifications Electrical verification System Design Verification System Design Validation Summative Usability Business requirements Software Design Specifications Unit Verification Integration Verification Formative Usability Testing Risk management
Contact Information DIGITAL DIGITAL HEALTH LEGAL AND HEALTH REGULATORY LEGAL BOOTCAMP AND WHAT REGULATORY YO DON T KNOW YOU DON T KNOW BOOTCAMP WHAT YOU DON T KNOW YOU DON T KNOW FDA Regulatory Expert Over 30 years of experience in the medical device, health information technology, and invitro diagnostics ( IVD ) industries. SCOTT THIEL, MT(ASCP), MBA, RAC Director, Navigant 317.272.5421 scott.thiel@navigant.com