Uploaded bymentoresd
PDF, PPTX8,553 views

Getting Your Medical Device FDA Approved

This document summarizes key information from a seminar on getting medical devices approved by the FDA. It discusses common reasons why companies fail FDA approval, including inadequate software documentation. The document outlines FDA guidance and standards for software documentation, design, validation, and human factors. It also discusses FDA concerns about cybersecurity for networked devices and provides an overview of FDA guidance on managing cybersecurity risks.

Embed presentation

Download as PDF, PPTX
mentor.com/embedded Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Qt is a registered trade mark of Digia Plc and/or its subsidiaries. All other trademarks mentioned in this document are trademarks of their respective owners. Seminar June 2014 Getting Your Medical Device FDA Approved
2
Why and How Companies Fail  Software documentation inadequate; includes: *  not provided at all,  missing description,  missing traceability matrix,  missing list of anomalies, and/or  missing validation * “Analysis of Pre‐Market Review Times Under the 510(k) Program,” US Food and Drug  Administration,  CDRH, November 9, 2011 Affects 17% of  submissions! 3
Why and How Companies Fail Source: “Medical Device Recall Report: FY2003 to FY2012,” US Food and Drug Administration,  CDRH, March 21, 2014 “Failure to implement software design controls, and where  appropriate, testing procedures, as well as increasing complexity of  the medical device use environment (with increased connectivity and  interoperability) can lead to software anomalies often requiring a  correction or removal.” Software  Change Control Software  Design S/W Design  (Mfg.) Sum % of CDRH  Recalls 2008 13 141 2 156 18.3% 2009 9 111 1 121 15.4% 2010 4 73 3 80 8.9% 2011 11 182 10 203 15.8% 2012 12 169 5 186 15.5% Total 49 676 21 746 15.1% 4
Why and How Companies Fail “Failure to follow or otherwise address current guidance  document(s) or recognized standards ‐ FDA issues  guidance documents or recognizes a national or international  standard to help manufacturers determine what information  to include in a 510(k) submission generally and for certain  device types specifically. If a manufacturer fails to follow  current guidance (i.e. that which is up‐to‐date) for a  certain device type or a recognized standard, and offers  no explanation for its failure to do so, FDA would  consider that submission to be of poor quality and would  issue an AI Letter that quotes current guidance to obtain the  missing information.” * “Analysis of Pre‐Market Review Times Under the 510(k) Program,” US Food and Drug  Administration,  CDRH, November 9, 2011 41% of submissions affected! 5
The Primary Roadmap  Guidance for the Content  of Premarket Submissions  for Software Contained in  Medical Devices  http://www.fda.gov/MedicalDevices/  DeviceRegulationandGuidance/  GuidanceDocuments/ucm089543.htm (Issued in 2005) 6
FDA Software Guidance  Software “level of concern”  Estimate (in the absence of mitigations) of the severity  of injury that a device failure or latent design flaw could  permit or inflict, either directly or indirectly, on a  patient or device operator:  Major: could result in death or serious injury   Moderate: could result in minor injury  Minor: unlikely to cause any injury  Documentation FDA recommends submitting  depends on the level of concern 7
Software‐related Documentation  Overview  Describe the design of your device  Document how your design was implemented  Demonstrate how the device produced by your design  implementation was tested  Show that you identified hazards appropriately and  managed risks effectively  Provide traceability to link together  design,  implementation, testing, and risk management 8
Software‐related Documentation  Device Hazard Analysis  Address all foreseeable hazards  (including intentional or inadvertent  misuse)  Identification of the hazardous event  Severity of the hazard  Cause(s) of the hazard  Method of control (e.g., alarm, hardware  design)  Corrective measures to eliminate, reduce, or  warn  Verification of correct control  implementation 9
Software‐related Documentation  Software Requirements Specification  Hardware Requirements  Programming Language Requirements  SW Performance and Functional Requirements  Architecture Design Chart  Software Design Specification  Traceability Analysis  SW Development Environment Description  V&V Documentation  Revision Level History  Unresolved Anomalies (Bug List) 10
Software Development Standard  IEC 62304:2006  Medical device software – Software life cycle  processes  SW development  SW maintenance  SW risk management   SW configuration  management  SW problem  resolution 11
Overview – IEC 62304:2006  Describes software development and maintenance  processes for medical devices but does not specify:  An organizational structure or responsibilities  The name, format or explicit content of documentation  The specific life‐cycle model to be employed  FDA Consensus Standard (September 2008)  IEC62304 conformance fulfills the “Software Development  Environment Description” section of a 510(k) submission  Normative standard in Europe for CE marking 12
Software Verification and Validation (V&V)  MINOR LOC:  System or device level testing, any integration testing  Pass/fail criteria  Summary of test results  MODERATE LOC:  V&V activities at the unit, integration, and system level  Summary list of V&V activities  Pass/fail criteria  Test results  MAJOR LOC:  V&V activities at the unit, integration, and system level  Unit, integration and system‐level test protocols  Pass/fail criteria  Test report, summary, test results 13
Software‐Related Documentation  General Principles of  Software Validation:  Final Guidance for  Industry and FDA Staff  http://www.fda.gov/  MedicalDevices/  DeviceRegulationand Guidance/  GuidanceDocuments/  ucm085281.htm (Issued in 2002) 14
Software Design and Human Factors  Weave human factors engineering into entire design and  development process, including device design  requirements, analyses, and tests  Consider device safety and usability issues when  developing flowcharts, state diagrams, prototyping tools,  and test plans  Perform task and function analyses, risk analyses,  prototype tests and review, and full usability tests  Include participants from the user population(s) 15
Common User Interface (UI) Issues  UI complexity causes user confusion, delay in use,  or inability to use the device  UI makes it difficult for user to correct data entry  errors or modify device settings in a timely  fashion  UI falsely causes the user to believe a critical  situation exists when it does not, or vice‐versa  UI does not draw attention to dangerous  conditions of device operation or patient status  UI does not prevent known, likely data input  errors  16
Regulatory Basis for Human Factors  21 CFR 820.30, Design Controls (The need for human  factors is implied):  Design input – includes “needs of the user and  patient”  Design verification – performance criteria met  Design validation – “… devices conform to defined  user needs and intended uses and shall include  testing of production units under actual or  simulated use conditions. Design validation shall  include software validation and risk analysis….”  [incl. use‐related risks] 17
Human Factors Standards AAMI/ANSI HE75:2009 Human factors engineering – Design of medical devices 18 ISO/IEC 62366:2007 Medical devices – Application of  usability engineering to medical devices
FDA Human Factors Guidance  Applying HF&UE to  Optimize Medical  Device Design  http://www.fda.gov/  MedicalDevices/  DeviceRegulationand Guidance/  GuidanceDocuments/  ucm259748.htm   NOTE: issued in 2011 –It  is not yet in effect but it  reflects FDA‐CDRH’s  current thinking and  approach to human  factors 19
2011 Draft Human Factors Guidance FDA’s best thinking regarding:   Device Users, Use Environments and User Interfaces  Use‐Related Hazard Analytical Methods  Formative Evaluations  Mitigation and Control of Use‐Related Hazards  Design Verification Testing  Human Factors Validation 20 “Use error caused by designs that are either overly complex or contrary  to users' intuitive expectations for operation is one of the most  persistent and critical problems encountered by FDA.” ‐ General Principles of Software Validation, Final Guidance for Industry and FDA Staff  (2002)
Submission Problems with HF/UE  Not understanding that “usability goals” are not included  in FDA’s recognition of the standard  Simply state “in compliance” with 62366 and submit no HF  report  Not using US residents in validation studies (w/exceptions)  Devices modified to mitigate use error issues, then the  mitigation is not directly tested in validation testing  Formative evaluations either not done or pretending to be  validation testing  Overemphasis on complex protocol, technique, and test  conditions while the test focus, data, interpretations and  report are impossible to interpret.  21
A Good HF/UE Validation Report Includes:  Intended device users, uses, use environments,  and training  Device user interface (graphical & verbal  description)  Summary of known use problems  User task selection, characterization and  prioritization  Summary of formative evaluations  Validation testing 22
Validation Testing  Rationale for test type selected (i.e., simulated use or  clinical evaluation)   Number and type of test participants and rationale for  how they represent the intended user populations   Test goals, critical tasks and use scenarios studied   Technique for capturing unanticipated use errors   Definition of performance failures   Test results: Number of device uses, success and failure  occurrences   Subjective assessment by test participants of any critical  task failures and difficulties   Description and analysis of all task failures, implications  for additional risk mitigation 23
FDA’s Cybersecurity Concern  Network‐connected devices disabled by  malware  Targeting of patient data using wireless  technology  Uncontrolled passwords management  Failure to address security vulnerabilities via  update  Security vulnerabilities in OTS software ‐ Source:  FDA Safety Communication (June 13, 2013) 24
FDA Cybersecurity Guidance  Content of Premarket  Submissions for  Management of  Cybersecurity in  Medical Devices  http://www.fda.gov/  MedicalDevices/  DeviceRegulationand Guidance/  GuidanceDocuments/  ucm356186.htm   NOTE: issued in 2013 –It is  not yet in effect but it  reflects FDA‐CDRH’s current  thinking and approach to  cybersecurity 25
2013 Draft Cybersecurity Guidance General Principles:  Confidentiality – only authorized persons or  entities have access  Integrity – Accurate and complete data, not  improperly modified  Availability – Accessible and usable on a  timely basis in the expected manner 26
2013 Draft Cybersecurity Guidance Documentation:  Hazard analysis addressing intentional and  unintentional cybersecurity risks  Traceability matrix linking controls to risks  Systematic plan for updates and patches  Demonstrate how the device will be  provided free of malware  IFU and specs for recommended anti‐virus  s/w and/or firewall 27
Conclusions:  Buy a copy of device‐relevant standards  Get free FDA guidance documents online  Read them  Gap assess your processes and current  records – then fix them  implement tools that drive consistent  outputs  Hire a HF/UE Engineer (or make a  consultant happy) 28
Thank You! For questions or assistance, contact me at  srobert999@gmail.com or (972) 505‐1920 29
The Standard ‐ Illustrated 30
Medical Device Software under IEC 62304 George Romanski
© IEC 62304 • Medical Device Software – Software Lifecycle  Processes – Quality Management System* – RISK MANAGEMENT – Software Safety Classification – Development Process – Maintenance Process – Configuration Management* – Problem Reporting and Management* IEC‐62304 Medical Software * These processes are Universal between the standards
© Software Safety Assessment • For Avionics – ARP‐4761 (Safety Assessment)  • For Medical – ISO 14971 (Safety/Risk) Normative reference  • For Automotive  – Part of ISO 26262 • For Industrial – Part of IEC 61508 • For Trains – Part of EN 50128 IEC‐62304 Medical Software Different terms:  Design Assurance Level, Software Integrity Level, Class Same Principle: Consequence/Exposure, Severity ‐> Level for software Level chosen for System  then applied to Software ‐‐‐ How do you assess for RTOS?
© What level is Device Software?  • Software Faults do not follow “Gauss Normal”  Distribution (Bell Curve) – Given 10,000 lines of code – You test and find 10 software faults – What is the probability of finding another fault  with another test? • We Don’t know distribution of faults • Software must be assumed to be level C until  shown by Risk Assessment that a lower level is  applicable!  IEC‐62304 Medical Software
© Software Risks • Does it do what it should? • Does it do More than it should? • It does something wrong • Is an action late • Is an action too early • Are a sequence of actions in the wrong order? How can we be sure?  “enough” ALARP – As Low as Reasonably Practicable (RISK) IEC‐62304 Medical Software
© Software of Unknown Provenance (SOUP) RTOS Software (SOUP) Tasks Tasks Tasks Semaphores Semaphores ISRs Kalman Filter  Software (SOUP) “Wrapper” With ‘thin’ interface Medical Device Application Message  Queues Message  Queues ‘others’ Behavior managed by RTOS IEC‐62304 Medical Software
© Software of Unknown Provenance (SOUP) RTOS Software (SOUP) Tasks Tasks Tasks Semaphores Semaphores ISRs Kalman Filter  Software (SOUP) “Wrapper” With ‘thin’ interface Medical Device Application Message  Queues Message  Queues ‘others’ Behavior managed by RTOSDifferent SOUPs IEC‐62304 Medical Software
© Failure conditions potentially induced by RTOS • Data is incorrectly modified.  • Incorrect results are provided to the application. • Expected results are not provided or are provided past their  deadlines. • User code is not executed as expected (not run, incorrectly  run, and incorrectly sequenced). • Fault conditions are not detected. • Fault conditions are handled incorrectly. • False failure conditions are reported. • Incorrect or untimely response provided by the RTOS to  external or user generated events. IEC‐62304 Medical Software
© Failure conditions potentially induced by RTOS • Data is incorrectly modified.  • Incorrect results are provided to the application. • Expected results are not provided or are provided past their  deadlines. • User code is not executed as expected (not run, incorrectly  run, and incorrectly sequenced). • Fault conditions are not detected. • Fault conditions are handled incorrectly. • False failure conditions are reported. • Incorrect or untimely response provided by the RTOS to  external or user generated events. IEC‐62304 Medical Software Reduce risk by Using Certified  RTOS
© Managing Risk ‐ ISO 14971 Risk Management Plan Identify Risks Evaluate Control Verify Risk Management Processes Risk Management File IEC‐62304 Medical Software
© Medical Device – Based on Risk Assessment Develop  Hardware Develop  Software Integrate System Risk Analysis Risks Functional Requirements System IEC‐62304 Medical Software
© System Hazard – Software Class • System Hazard – No Injury – A – Non‐Serious injury – B – Death or Serious injury – C • If failure in Software leads to System Hazard • Software categorizes as – Class – A – Class – B – Class – C IEC‐62304 Medical Software ISO 14971 IEC 62304
© Risk Analysis • Failure Mode Analysis • Identify Potential Risks • Determine Risk Exposure – Continuous while operational – Frequent – Occasional • Can Software contribute to Hazards • Can Hazards be mitigated • Finding potential hazards in Software can be TOUGH! IEC‐62304 Medical Software
© Requirements Hierarchies – DO‐178B System Requirements High‐Level Requirements Low‐Level Requirements ARP 4754A Intended  System Behavior Intended  Software Behavior DO‐178C Requirements based on Software Architecture IEC‐62304 Medical Software
© Requirement/Design organization Risk Management Requirements Low‐Level Design ISO 14971 Intended  System Behavior Intended System/  Software Behavior IEC 62304 Software based on Requirements IEC‐62304 Medical Software
© Parameter Data Items  • Parameter Data Items can be developed and verified  separately if certain conditions are met • The high‐level requirements describe how the software uses  the parameter data items • The low‐level requirements define the structure, attributes  and allowable values of the parameter data items • Verification should show that every data element has the  correct value – or correct value is in equivalence class and  boundaries are verified e.g. Configuration Vectors IEC‐62304 Medical Software
© Our Experience • Develop verification evidence using a DO‐178C  software Lifecycle • All of the other Lifecycle processes will fall into  place.  • Some additional documents required – Safety Plan – Safety Manual – Staff Competency Assessment • Actual assessment required not just Resume IEC‐62304 Medical Software
© More Experience  • Interpretations and negotiations are prevalent  in Automotive, Medical and Rail industries. • TUV were strict on first Verocel certification – Plans, procedures and standards approved – Subsequent certifications were straightforward – “Manufacturing – reject tracking” needed to be  addressed (for software)?   IEC‐62304 Medical Software
© Finding and eliminating unintended behavior • Requirements describe intended behavior • Software developed against requirements (TRACED) • Tests written against requirements (ONLY) and  (TRACED) • Software coverage by tests measured • Any software not covered demonstrates “unintended  behavior”  • This is a risk that must be eliminated.    IEC‐62304 Medical Software
© Code Coverage Analysis • Requirements used to specify intended behavior • Write tests using Requirements ONLY – Normal Range – Robustness – Equivalence Class – Boundary Value • Run tests and measure how much code was executed • Assess is non‐executed code should not be there Coverage Analysis not required explicitly by IEC 62304, but Hard to mitigate “Unintended Functionality risk” without IEC‐62304 Medical Software
© Coding Standards • Standards Required – used to show goodness of  various properties • Code Layout • Code consistency • Readability • Avoidance of risky constructs • Etc.   IEC‐62304 Medical Software
© Code Review • Verifies Conformance to Standards • Verifies conformance to review criteria • Verifies code against intended behavior – Low‐level Design – Low‐level requirements IEC‐62304 Medical Software
© Code Analysis Tools (The silver bullet?) • Perform consistency checks • Perform checks against defined coding rules  (e.g. MISRA C) to find errors like: – Use of variable before initialization – Indexing out of bounds (simple cases) – Potential deadlock – Unreachable code (sometimes) – Arithmetic overflow (sometimes) Good quality step, reduction of potential faults, BUT! IEC‐62304 Medical Software
© Code Analysis Tools for Certification • Checks are incomplete • Hard to assess what checks must be  completed manually • No analysis against intended behavior – Low‐level design – Low‐level requirements Only partial credit may be taken! IEC‐62304 Medical Software
© Configuration Management Processes  • Identification  – Versions – Baseline • Change Control  – Documented process – Change Control Board • Configuration Accounting – History tracking – Access Controls IEC‐62304 Medical Software
© Segregation of Software Components RTOS APP_One Class C APP_Two Class A Components can be segregated and  treated as Class C on same computer. Fault Containment Memory Partitioning Time Partitioning Required App‐Two cannot adversely affect Class C software IEC‐62304 Medical Software
© Audit Risk • Scenario 1 – Prepare Verification evidence on paper – Instruct Engineers to give YES/NO answers – All information available, but difficult to locate.  – Auditor cannot make good assessment – Applicant passes with substandard/incomplete audit.  Not the Verocel Way! IEC‐62304 Medical Software
© The Verocel Approach • Plans, QA records, CM‐data, and Certification  data:  – Hyperlinked data – easy to find and trace • All data open and put on DVD‐ROM – Auditors can trace their own copies • All data extracted from Traceability database,  and CM repository IEC‐62304 Medical Software
© • Develop Plans and  Standards • Develop Certification  evidence using P&S • QA Checks that  P&S are  followed • Review Plans and Standards • Sample Cert evidence • Check QA Audits Auditors approach  If a controlled process was used consistently  And Sample is good  Then we can trust the rest of the certification  evidence and the software AuditorsDevelopers/Certifiers IEC‐62304 Medical Software
mentor.com/embedded Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Qt is a registered trade mark of Digia Plc and/or its subsidiaries. All other trademarks mentioned in this document are trademarks of their respective owners. Andrew Caples June 2014 Mentor Embedded Solutions
2 mentor.com/embedded 2 Trends for Mixed Criticality  Needed to meet stringent non-functional requirements — Cost — Space — Weight — Heat generation — Power consumption  Issues — Partitioning for safety assurance — Sharing for efficient resource usage — Hard Tasks must be guaranteed — Soft Tasks given best possible service — Must ensure the behavior of low criticality components does not adversely impact the behavior of higher criticality components
3 mentor.com/embedded 3 Memory Protected Memory Protected Memory Protected Memory Protected Nucleus Processes  Memory Protected Modules — Prevents sub-systems from bringing down the system — No Virtual Addressing  Multiple Types — Applications — Libraries — Hybrids  Integrated with Sourcery CodeBench — Build projects via wizards — Debug / load modules — Profile module execution File Systems Peripheral Bus Drives GUINetworking Power Aware Kernel StorageLCD Ethernet/ Wireless Devices Memory Protected Application 1 Task 1 Task 2 … Task n Library 1 Function 1 Function 2 … Function n Hybrid 1 Task 1 Function 1 … Task n Function n Application 2 Task 1 Task 2 … Task n
4 mentor.com/embedded 4 Nucleus Process Model Root Kernel Image User Process n User Process 2 User Process 3 Hardware User Process 1 User Process 2
5 mentor.com/embedded 5 Foreground / Background Mode Static Application Root Kernel Image User Process n User Process 2 User Process 3 Hardware User Process 1 User Process 2
6 mentor.com/embedded 66 Mentor Embedded Offerings
7 mentor.com/embedded 77 Mentor Embedded United States Canada United Kingdom Ireland Netherlands Germany Denmark Sweden Finland Poland Armenia Russia China Japan Korea Taiwan Australia Singapore India Pakistan Israel Egypt Hungary ItalyAustria Switzerland Spain France Brazil 400+ engineers 50+ engineers in lead OSS community roles 10,000+ accepted OSS changes Deployed in 3 Billion+ devices 20,000+ Sourcery CodeBench users “Since 1996, Mentor Graphics has been the only EDA vendor with a broad product line of embedded tools and software IP. Integrating our software and hardware expertise more readily enables our customers to deal with the challenges of today’s multicore and power management complexities.” Walden Rhines, CEO

More Related Content

PDF
FDA 510(k) Submission Tips & Best Practices
byGreenlight Guru
 
PDF
Clinical evaluation
byI 3 Consulting
 
PPTX
Medical Devices Regulation (MDR) 2017/745 - Postmarket surveillance
byArete-Zoe, LLC
 
PDF
Building a QMS for Your SaMD Part II
byEMMAIntl
 
PDF
Understanding IEC 62304
byMethodSense, Inc.
 
PPTX
Medical Devices Regulation (MDR) 2017/745 - Clinical investigations
byArete-Zoe, LLC
 
PDF
UDI in Medical Devices
byAjit Pattnaik
 
PDF
The European Medical Device Regulations - analysis of the final text
bypi
 
FDA 510(k) Submission Tips & Best Practices
byGreenlight Guru
 
Clinical evaluation
byI 3 Consulting
 
Medical Devices Regulation (MDR) 2017/745 - Postmarket surveillance
byArete-Zoe, LLC
 
Building a QMS for Your SaMD Part II
byEMMAIntl
 
Understanding IEC 62304
byMethodSense, Inc.
 
Medical Devices Regulation (MDR) 2017/745 - Clinical investigations
byArete-Zoe, LLC
 
UDI in Medical Devices
byAjit Pattnaik
 
The European Medical Device Regulations - analysis of the final text
bypi
 

What's hot

PDF
UDI
byPavan Kumar Malwade
 
PPTX
21 CFR 820....pptx
byGayathriGuhan
 
PDF
Canada medical device approval chart - EMERGO
byEMERGO
 
PDF
FDA UDI vs EU UDI
bymitchellrobertss
 
PDF
ISO 14155 Clinical investigation of medical devices for human subjects- Good ...
byketakeephadnis
 
PDF
CER - PMS - PMCF
byKatarzyna Zofia Chrusciel
 
PPTX
Quality System Requirements 21 CFR Part 820 and Labelling Requirements for Me...
bySwapnil Fernandes
 
PDF
Icmr dbt stem cell guidelines
byDr.Dinesh Shende
 
PPTX
Medical Devices Regulation (MDR) 2017/745 - Classification of devices
byArete-Zoe, LLC
 
PPT
Deviation control system
byDeepak Amoli
 
PPTX
Clinical Evaluation of Medical Devices
byArete-Zoe, LLC
 
PPTX
Good distribution practices for API's
byGMP EDUCATION : Not for Profit Organization
 
PDF
Risk Management for Medical Devices - ISO 14971 Overview
byGreenlight Guru
 
PPTX
Post marketing surveillance in Japan, legislation and.pptx
byDimple Marathe
 
PPTX
ISO-13485-2016.pptx
byPradeepa J
 
PDF
China: Medical Device Regulations
byPacific Bridge Medical
 
PPTX
GLOBAL MEDICAL DEVICES NOMENCLATURE.pptx
bySanthiNori1
 
PDF
Saudi arabia medical device regulatory process
byEMERGO
 
PPTX
Computer System Validation
byGMP EDUCATION : Not for Profit Organization
 
PPTX
Good Automated Laboratory Practices
bySwapnil Fernandes
 
UDI
byPavan Kumar Malwade
 
21 CFR 820....pptx
byGayathriGuhan
 
Canada medical device approval chart - EMERGO
byEMERGO
 
FDA UDI vs EU UDI
bymitchellrobertss
 
ISO 14155 Clinical investigation of medical devices for human subjects- Good ...
byketakeephadnis
 
CER - PMS - PMCF
byKatarzyna Zofia Chrusciel
 
Quality System Requirements 21 CFR Part 820 and Labelling Requirements for Me...
bySwapnil Fernandes
 
Icmr dbt stem cell guidelines
byDr.Dinesh Shende
 
Medical Devices Regulation (MDR) 2017/745 - Classification of devices
byArete-Zoe, LLC
 
Deviation control system
byDeepak Amoli
 
Clinical Evaluation of Medical Devices
byArete-Zoe, LLC
 
Good distribution practices for API's
byGMP EDUCATION : Not for Profit Organization
 
Risk Management for Medical Devices - ISO 14971 Overview
byGreenlight Guru
 
Post marketing surveillance in Japan, legislation and.pptx
byDimple Marathe
 
ISO-13485-2016.pptx
byPradeepa J
 
China: Medical Device Regulations
byPacific Bridge Medical
 
GLOBAL MEDICAL DEVICES NOMENCLATURE.pptx
bySanthiNori1
 
Saudi arabia medical device regulatory process
byEMERGO
 
Computer System Validation
byGMP EDUCATION : Not for Profit Organization
 
Good Automated Laboratory Practices
bySwapnil Fernandes
 

Viewers also liked

PDF
US FDA medical device approval chart - Emergo
byEMERGO
 
PDF
FDA Regulations and Medical Device Pathways to Market
byMethodSense, Inc.
 
PDF
Overview of FDA Regulation of Medical Devices
byMichael Swit
 
PPT
Understanding FDA Requirements Medical Devices
bymarchell
 
PPTX
Regulation of Medical Devices in US
byAnkit Geete
 
PDF
Regulatory Approval Process for Medical Devices in EU - Presentation by Aksha...
byAkshay Anand
 
PDF
The FDA - Mobile, and Fixed Medical Devices Cybersecurity Guidance
byValdez Ladd MBA, CISSP, CISA,
 
PDF
Human factor standards and usability (by Ed Israelski)
byStella Tsank
 
PDF
Medical Device Regulations Global Overview And Guiding Principles
byJacobe2008
 
PDF
Steps to Compliance with the European Medical Device Regulations
byApril Bright
 
PDF
Webinar: Europe's new Medical Device Regulations (MDR)
byEMERGO
 
PPTX
Medical device
bybdvfgbdhg
 
PPTX
Pharmacovigilence
byUSmile Ï Ṩṃïlệ
 
PDF
Agile Development And Medtech
byRobert Ginsberg
 
PDF
Covidien - FDA Guidance on Mobile Medical Apps 140124
byJason Haislmaier
 
PDF
FDA Medical Device Guidance
byMarket iT
 
PDF
Surgical Device Sales Expert
byJason Baker
 
PPT
Device Classification John V.
bybigjuan
 
US FDA medical device approval chart - Emergo
byEMERGO
 
FDA Regulations and Medical Device Pathways to Market
byMethodSense, Inc.
 
Overview of FDA Regulation of Medical Devices
byMichael Swit
 
Understanding FDA Requirements Medical Devices
bymarchell
 
Regulation of Medical Devices in US
byAnkit Geete
 
Regulatory Approval Process for Medical Devices in EU - Presentation by Aksha...
byAkshay Anand
 
The FDA - Mobile, and Fixed Medical Devices Cybersecurity Guidance
byValdez Ladd MBA, CISSP, CISA,
 
Human factor standards and usability (by Ed Israelski)
byStella Tsank
 
Medical Device Regulations Global Overview And Guiding Principles
byJacobe2008
 
Steps to Compliance with the European Medical Device Regulations
byApril Bright
 
Webinar: Europe's new Medical Device Regulations (MDR)
byEMERGO
 
Medical device
bybdvfgbdhg
 
Pharmacovigilence
byUSmile Ï Ṩṃïlệ
 
Agile Development And Medtech
byRobert Ginsberg
 
Covidien - FDA Guidance on Mobile Medical Apps 140124
byJason Haislmaier
 
FDA Medical Device Guidance
byMarket iT
 
Surgical Device Sales Expert
byJason Baker
 
Device Classification John V.
bybigjuan
 

Similar to Getting Your Medical Device FDA Approved

DOCX
Software Medical Device Documentation for 510(k) Submissions.docx
byI3CGLOBAL
 
PPTX
Lifetech Brussels phase I Medtech Accelerator - Software
byCyrille Michaud
 
PDF
Software Introduction & Tools
bycollegelisted
 
PDF
mHealth Israel_Digital Health_The Regulatory Landscape 2017
byLevi Shapiro
 
PDF
Rx for FDA Software Compliance
byParasoft
 
PPTX
FDA software compliance 2016
byEngineering Software Lab
 
PPTX
Critical Steps in Software Development: Enhance Your Chances for a Successful...
bySterling Medical Devices
 
PDF
When Medical Device Software Fails Due to Improper Verification & Validation ...
bySterling Medical Devices
 
DOCX
Software Validation for Medical Devices
byEMMAIntl
 
PDF
5 Key Considerations at the Start of SaMD Development
byICS
 
PPTX
Software Life Cycle Management for Medical Devices.pptx
byDash Technologies Inc
 
PPTX
Building a QMS for Your SaMD
byEMMAIntl
 
PDF
Software controlled electron mechanical systems reliability
byASQ Reliability Division
 
PDF
Appetite For Risk - Continuous Delivery In A Regulated Environment
byUXDXConf
 
PDF
Behind the Stats: Expectations vs. Reality of Bringing a Device to Market
byGreenlight Guru
 
DOCX
FDA’s Digital Software Pre-Certification Program
byEMMAIntl
 
PDF
Medical Device Software Verification Validation and Compliance 1 Har/Dvdr Edi...
bycordetkanqui69
 
PPT
Software design for_medical_devices_europe_conferent_19012011[1]
byErik Vollebregt
 
PPTX
Time to Money- Software Development for a Regulated Medical World
byDina Sifri
 
PPTX
An Overview for Software as a Medical Device (SaMD)
byDePuy Synthes
 
Software Medical Device Documentation for 510(k) Submissions.docx
byI3CGLOBAL
 
Lifetech Brussels phase I Medtech Accelerator - Software
byCyrille Michaud
 
Software Introduction & Tools
bycollegelisted
 
mHealth Israel_Digital Health_The Regulatory Landscape 2017
byLevi Shapiro
 
Rx for FDA Software Compliance
byParasoft
 
FDA software compliance 2016
byEngineering Software Lab
 
Critical Steps in Software Development: Enhance Your Chances for a Successful...
bySterling Medical Devices
 
When Medical Device Software Fails Due to Improper Verification & Validation ...
bySterling Medical Devices
 
Software Validation for Medical Devices
byEMMAIntl
 
5 Key Considerations at the Start of SaMD Development
byICS
 
Software Life Cycle Management for Medical Devices.pptx
byDash Technologies Inc
 
Building a QMS for Your SaMD
byEMMAIntl
 
Software controlled electron mechanical systems reliability
byASQ Reliability Division
 
Appetite For Risk - Continuous Delivery In A Regulated Environment
byUXDXConf
 
Behind the Stats: Expectations vs. Reality of Bringing a Device to Market
byGreenlight Guru
 
FDA’s Digital Software Pre-Certification Program
byEMMAIntl
 
Medical Device Software Verification Validation and Compliance 1 Har/Dvdr Edi...
bycordetkanqui69
 
Software design for_medical_devices_europe_conferent_19012011[1]
byErik Vollebregt
 
Time to Money- Software Development for a Regulated Medical World
byDina Sifri
 
An Overview for Software as a Medical Device (SaMD)
byDePuy Synthes
 

More from mentoresd

PPTX
Security for io t apr 29th mentor embedded hangout
bymentoresd
 
PPTX
Internet of Things Connectivity for Embedded Devices
bymentoresd
 
PPTX
Technology, Business and Regulation of the Connected Car
bymentoresd
 
PPTX
Meeting SEP 2.0 Compliance: Developing Power Aware Embedded Systems for the M...
bymentoresd
 
PPTX
How to Measure RTOS Performance
bymentoresd
 
PPTX
Profiling Multicore Systems to Maximize Core Utilization
bymentoresd
 
PDF
Developing the Next Generation Embedded HMIs
bymentoresd
 
PPTX
Simultaneously Leveraging Linux and Android in a GENIVI compliant IVI System
bymentoresd
 
PPTX
Power Management in Embedded Systems
bymentoresd
 
Security for io t apr 29th mentor embedded hangout
bymentoresd
 
Internet of Things Connectivity for Embedded Devices
bymentoresd
 
Technology, Business and Regulation of the Connected Car
bymentoresd
 
Meeting SEP 2.0 Compliance: Developing Power Aware Embedded Systems for the M...
bymentoresd
 
How to Measure RTOS Performance
bymentoresd
 
Profiling Multicore Systems to Maximize Core Utilization
bymentoresd
 
Developing the Next Generation Embedded HMIs
bymentoresd
 
Simultaneously Leveraging Linux and Android in a GENIVI compliant IVI System
bymentoresd
 
Power Management in Embedded Systems
bymentoresd
 

Recently uploaded

PPTX
Chapter 3 Introduction to number system.pptx
byGetachewAbera9
 
PDF
Our Digital Tribe_ Cultivating Connection and Growth in Our Slack Community 🌿...
bysanjeetmishra30
 
PDF
TrustArc Webinar - Looking Ahead: The 2026 Privacy Landscape
byTrustArc
 
PPTX
Cloud-and-AI-Platform-FY26-Partner-Playbook.pptx
byiuiuiuiu1
 
PPTX
Data Privacy and Protection: Safeguarding Information in a Connected World
byYasir Naveed Riaz
 
PDF
Internet_of_Things_IoT_for_Next_Generation_Smart_Systems_Utilizing.pdf
byRoshanSyed12
 
PDF
Day 3 - Data and Application Security - 2nd Sight Lab Cloud Security Class
by2nd Sight Lab
 
PDF
Digit Expo 2025 - EICC Edinburgh 27th November
byRay Bugg
 
PPTX
AI's Impact on Cybersecurity - Challenges and Opportunities
byYasir Naveed Riaz
 
PDF
Energy Storage Landscape Clean Energy Ministerial
bySurajitBanerjee38
 
PDF
Dev Dives: AI that builds with you - UiPath Autopilot for effortless RPA & AP...
byUiPathCommunity
 
PPTX
Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]
byUiPathCommunity
 
PPTX
Unit-4-ARTIFICIAL NEURAL NETWORKS.pptx ANN ppt Artificial neural network
byssuserd4481a
 
PPT
software-security-intro in information security.ppt
byismaeelsahib032
 
PPTX
Building Cyber Resilience for 2026: Best Practices for a Secure, AI-Driven Bu...
byYasir Naveed Riaz
 
PDF
Decoding the DNA: The Digital Networks Act, the Open Internet, and IP interco...
byCSUC - Consorci de Serveis Universitaris de Catalunya
 
PPTX
From Backup to Resilience: How MSPs Are Preparing for 2026
byMSP360
 
DOCX
iRobot Post‑Mortem and Alternative Paths - Discussion Document for Boards and...
byDave Litwiller
 
PDF
Usage Control for Process Discovery through a Trusted Execution Environment
byValerioGoretti
 
PDF
Unser Jahresrückblick – MarvelClient in 2025
bypanagenda
 
Chapter 3 Introduction to number system.pptx
byGetachewAbera9
 
Our Digital Tribe_ Cultivating Connection and Growth in Our Slack Community 🌿...
bysanjeetmishra30
 
TrustArc Webinar - Looking Ahead: The 2026 Privacy Landscape
byTrustArc
 
Cloud-and-AI-Platform-FY26-Partner-Playbook.pptx
byiuiuiuiu1
 
Data Privacy and Protection: Safeguarding Information in a Connected World
byYasir Naveed Riaz
 
Internet_of_Things_IoT_for_Next_Generation_Smart_Systems_Utilizing.pdf
byRoshanSyed12
 
Day 3 - Data and Application Security - 2nd Sight Lab Cloud Security Class
by2nd Sight Lab
 
Digit Expo 2025 - EICC Edinburgh 27th November
byRay Bugg
 
AI's Impact on Cybersecurity - Challenges and Opportunities
byYasir Naveed Riaz
 
Energy Storage Landscape Clean Energy Ministerial
bySurajitBanerjee38
 
Dev Dives: AI that builds with you - UiPath Autopilot for effortless RPA & AP...
byUiPathCommunity
 
Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]
byUiPathCommunity
 
Unit-4-ARTIFICIAL NEURAL NETWORKS.pptx ANN ppt Artificial neural network
byssuserd4481a
 
software-security-intro in information security.ppt
byismaeelsahib032
 
Building Cyber Resilience for 2026: Best Practices for a Secure, AI-Driven Bu...
byYasir Naveed Riaz
 
Decoding the DNA: The Digital Networks Act, the Open Internet, and IP interco...
byCSUC - Consorci de Serveis Universitaris de Catalunya
 
From Backup to Resilience: How MSPs Are Preparing for 2026
byMSP360
 
iRobot Post‑Mortem and Alternative Paths - Discussion Document for Boards and...
byDave Litwiller
 
Usage Control for Process Discovery through a Trusted Execution Environment
byValerioGoretti
 
Unser Jahresrückblick – MarvelClient in 2025
bypanagenda
 

Getting Your Medical Device FDA Approved