TwinSPIN_Lecture.ppt
Download as PPT, PDF0 likes17 views
The document discusses the FDA review process for medical device software. It provides an overview of regulatory requirements for software validation and guidelines for the content of pre-market submissions to the FDA. The summary should include documentation of hazards analysis, requirements specifications, design documentation, verification and validation testing results, and resolution of any unresolved anomalies. The level of documentation depends on the level of concern for the software.
TwinSPIN_Lecture.ppt
- 1. Center for Devices and Radiological Health U. S. Department of Health and Human Services Surviving an FDAAudit Richard Chapman, FDA TwinSPIN University of Minnesota January 14, 2010
- 2. Center for Devices and Radiological Health Who am I? Richard C. Chapman Software Engineer Food and Drug Administration Center For Devices and Radiological Health Office of Science and Engineering Laboratories Division of Software and Electrical Engineering WO62-4220 10903 New Hampshire Ave Silver Spring MD 20993-0002 richard.chapman@fda.hhs.gov (301) 796-2585
- 3. Center for Devices and Radiological Health Government Laws & Agencies Regulations Guidances Standards Regulatory Hierarchy
- 4. Center for Devices and Radiological Health Model for reasonable assurance Management Quality systems Design controls Engineering Software standards and practice Specific steps to ensure safety Risk management Software Message
- 5. Center for Devices and Radiological Health The disciplined, methodical approach used to create a sound software design, implement it, and ensure that changes are effective. Software Engineering
- 6. Center for Devices and Radiological Health The FDA has issued Regulations that require software validation A regulation for electronic records and signatures Guidance related to software validation Guidance for software information in premarket submissions Regulatory Background
- 7. Center for Devices and Radiological Health Two Types of Software Device Subject to 510(k), IDE, PMA premarket submissions 820.30 design controls/validation inspections Production and Quality Systems (includes software used for clinical trials Subject to inspections only Part 820.70(i) Part 11 Regulatory Background
- 8. Center for Devices and Radiological Health Software delivered to customers Software embedded in instruments Software as part of a system Standalone software Software used in production or in the quality system Internally developed software Purchased software Configured applications (e.g. Excel spreadsheets) eRecords Validation is Required for
- 9. Center for Devices and Radiological Health Medical Devices Submissions to FDA IDE - Investigation Device Exemption 510(k) – Substantial Equivalence PMA - Premarket Application HME – Humanitarian Device Exemption Safe and Effective Intended Use Indications for Use “Least Burdensome”
- 10. Center for Devices and Radiological Health Quality System Regulation Design Controls Where does software fit in? SECTION A. GENERAL I. REQUIREMENTS § 820.30(a) General. Each manufacturer of any class III or class II device, and the class I devices listed in paragraph (a) (2) of this section, shall establish and maintain procedures to control the design of the device in order to ensure that specified design requirements are met. The following class I devices are subject to design controls: (i) Devices automated with computer software; and …
- 11. Center for Devices and Radiological Health How Do Design Controls Work? Via mechanisms to provide visibility (i.e., means to measure the controlled variable) throughout the development process Via documented procedures to exercise continuous (or at least frequent) control of resources (i.e., feedback mechanisms) Via a semantic structure (language, taxonomy) to facilitate communications
- 12. Center for Devices and Radiological Health What Are The Limitations? Design controls do not assure the quality of products and services (but they provide a framework for assessing and documenting quality). Design controls do not completely eliminate design errors (but they prevent many errors and facilitate finding and correcting errors earlier in the development process). Management still needs the right people and the right tools to do the design work and review the results for adequacy.
- 13. Review verification Validation Needs & Intended Uses Require- ments Design Input Process Stage 1 Design Output Final Design Output Initial Design Stage ... Nth Design Stage Production Test Articles Possible Interim Reviews
- 14. Center for Devices and Radiological Health QSR versus Pre-market submissions Device manufacturers may use the same procedures and records for compliance with quality system and design control requirements, as well as for pre-market submissions to FDA. Specific safety or effectiveness issues related to software validation
- 15. Center for Devices and Radiological Health Guidance Documents General Principles of Software Validation Guidance for Off-the-Shelf Software Use in Medical Devices Guidance for Industry - Cybersecurity for Networked Medical Devices Containing Off- the-Shelf (OTS) Software Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices
- 16. Center for Devices and Radiological Health Websites http://www.accessdata.fda.gov/scripts/cdrh/cf docs/cfggp/search.cfm search “software” http://www.fda.gov/cdrh/humanfactors for human factors information
- 17. Center for Devices and Radiological Health The Review Process
- 18. Center for Devices and Radiological Health Content of Pre-market Submission
- 19. Center for Devices and Radiological Health Level of Concern Choose the appropriate level of concern Minor, Moderate, Major Key Questions Assess the Level of Concern before mitigating any hazard; that is, you should assess your software device against these questions as though you have not implemented hazard mitigations
- 20. Center for Devices and Radiological Health Level of Concern FDA reviewers examine: Device Description from pre-market submission Software Description Hazard Analysis Software Requirements Opinion of Domain and Software Experts Precedent
- 21. Center for Devices and Radiological Health Level of Concern Drives the documents that you submit to FDA in a pre-market submission. Ideally documentation should be artifacts from your design control activities If the FDA reviewer disagrees with your assessment of level of concern, it should be a simple photocopy exercise to provide the additional documentation requested.
- 22. Center for Devices and Radiological Health Software Description A summary overview of the features and software operating environment.
- 23. Center for Devices and Radiological Health Device Hazard Analysis Tabular description of identified hardware and software hazards, including severity assessment and mitigations.
- 24. Center for Devices and Radiological Health SRS Software Requirements Specification A triad Functions What the device does Performance Accuracy, speed, reliability, environmental influences Interfaces Input/output, power, data protocols, user interface
- 25. Center for Devices and Radiological Health Requirements—Guiding Principles Must specify what is needed, not the solution Complete to an engineering level of detail Requirements are developed by engineers, not by marketing department or users Adequacy Unambiguous (objectively verifiable) Quantitative limits expressed with a realistic measurement tolerance Self-consistent Environment completely characterized Completeness and relevance of external references
- 26. Center for Devices and Radiological Health Architecture Design Chart Detailed depiction of functional units and software modules. May include state diagrams as well as flow charts.
- 27. Center for Devices and Radiological Health Software Design Specification Software design specification document.
- 28. Center for Devices and Radiological Health Traceability Analysis Traceability among requirements, specifications, identified hazards and mitigations, and Verification and Validation testing.
- 29. Center for Devices and Radiological Health Software Development Environment Description Summary of software life cycle development plan. Annotated list of control documents generated during development process. Include the configuration management and maintenance plan documents.
- 30. Center for Devices and Radiological Health V & V Documentation Description of V&V activities at the unit, integration, and system level. Unit, integration and system level test protocols, including pass/fail criteria, test report, summary, and tests results.
- 31. Center for Devices and Radiological Health V & V Verification = assessing conformance to requirements (did I do the design right?) Validation = objective evidence that devices fulfills intended use (did I do the right design?) I.e., verification is details-oriented and validation is a cumulative summation of all efforts to assess suitability of design. Validation almost always includes user evaluation.
- 32. Software V&V REQUIREMENTS DEFINITION PRELIMINARY DESIGN DETAILED DESIGN CODING v v v V V V v V = VERIFY = VALIDATE LEGEND
- 33. Center for Devices and Radiological Health V & V—Guiding Principles V & V encompasses many activities: Tests, Inspections, and Analyses on the final version of software. V & V overlaps with design review to some extent. Companies may draw the dividing line anywhere reasonable. The design records should contain one or more verification and validation reports which summarize V & V activities, explain discrepancies, and document approvals.
- 34. Center for Devices and Radiological Health Design Reviews The cycle is: Design Audit (V&V) Review Resolution of review findings Not all “problems” detected by reviewers are real, or need to be corrected. There should be a procedure for tracking concerns and ensuring follow-up. There should be a procedure for resolving differences of opinion. Design review procedures should identify who is in charge.
- 35. Center for Devices and Radiological Health Revision Level History Revision history log, including release version number and date.
- 36. Center for Devices and Radiological Health Unresolved Anomalies List of remaining software anomalies, annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors. The software guidance is vague about what “indicate the problem” means. Many sponsors simply list the symptoms of the problem.
- 37. Center for Devices and Radiological Health Unresolved Anomalies Determine the root cause, i.e., put your finger on the problem. Point to the problem in the source code. Search code base for other occurrences of the software pattern, idiom, expression, or other software formulation that resulted in the defect that caused the observed anomaly. Coupling analysis
- 38. Center for Devices and Radiological Health Current Thinking IEC 62304 Automated Analysis Tools Assurance Cases