Critical Steps in Software Development: Enhance Your Chances for a Successful FDA Submission
-
Upload
sterling-medical-devices -
Category
Devices & Hardware
-
view
310 -
download
0
Transcript of Critical Steps in Software Development: Enhance Your Chances for a Successful FDA Submission
Critical Steps in Software Development Enhance Your Chances for a Successful FDA Submission
Select USAUS Embassy, Tokyo, June 10th, 2014US Consulate, Osaka, June 13th, 2014
Daniel Sterling, President Erik Hilliard, Director
What we do:o System Design, Development and Test
Software and Electronics Experts Smartphone Application Experts Any Phase
o Risk planning and hazard identificationo DHF Remediationo Project Rescueo Quality System Consulting
450+ Medical Projects, 125+ Clients
Who is Sterling?
ISO 13485FM 543438
Registered
IEC 62304 Compliant
Your Partner in Medical Device Development
There when you need us!
The Critical Steps
1. Decide whether your system is a medical device or medical device accessory
2. Determine the class of the device and the appropriate “level of concern” of the software– There may be specific regulations (21 CFR xxx) for your device type that
determine class
3. Establish a Quality System (21 CFR 820 – QSR, ISO 13485)– Establish a compliant software development lifecycle (IEC 62304)
4. Develop Software Under Design Controls– Identify and mitigate hazards and risks
Is Your App/System a Device?
In the United States
LAW (FD&C Act)
Regulation (21CFRxxx)
FDA Guidance
ANSI / AAMI / ISO / IEC Standards
Medical Device Defined
Section 201(h) of the FD&C Act:
“…an instrument, apparatus, implement, machine, contrivance, implant, in vitro
reagent…..”, that is “…intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man…” or “…intended to affect the structure or any function of the body of man or other animals…”
Is Your App/System a Device?
Intended Use
21 CFR 801.4:
… may, for example, be shown by labeling claims, advertising matter, or oral or written statements by such persons or their representatives.
… by the circumstances that the article is, with the knowledge of such persons or their representatives, offered and used for a purpose for which it is neither labeled nor advertised.
Is Your App/System a Device?
What if my Software is a Medical Device?
Impacts Design/DevelopmentImpacts MaintenancePMA or 510K?If PMA, Clinical Data is Needed
Risk Risk Risk
Assess, Mitigate, Test & Trace… and Repeat
How Much Determined by Class and LOC
Impact on Design/Development
Impact on Maintenance
Active Surveillance Program• Relationship with vendor(s)• Gather field/use information
Configuration ControlUpdate/Validate – likely frequent
Underlying FDA Guidance for Software Design/Development:
• Guidance for Industry and FDA Staff -- Guidance for the Content of Premarket Submissions for Software Contained in Medical Device, May 11, 2005http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm089543.htm
Defines Level of Concern• Major
– … directly or indirectly result in death or serious injury to the patient or operator. • Moderate
– … directly or indirectly result in minor injury to the patient or operator. • Minor
– … unlikely to cause any injury to the patient or operator.
What Documents to Submit to FDA, Depending on LOC Requires Software Development Life Cycle (SDLC) ( IEC 62304 ) Requires Risk Management ( ISO 14971 )
Standards Organizations
ANSI – American National Standards Institute
AAMI – Association for the Advancement of MedicalInstrumentation
ISO – International Organization For Standards
IEC – International Electrotechnical Commission
EN – European Norm
FDA Acceptance of Standards:A standard from any standards body may be acceptable to some extent; check at:
Standards Search (for recognition):http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfStandards/search.cfm
New Draft Guidance:Appropriate Use of Voluntary Consensus Standards in Premarket Submissions for Medical Devices
http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm396209.htm
What is IEC 62304?
Relationship:
Risk Management - Post Production
(All Medical Devices)
Risk Management - Plan - Methodology
Design ControlsDocumentation Controls
Quality RecordsEtc.
RequirementsArchitecture
Design ImplementationVerificationValidation
Modification
IEC 60601-1-4
ISO/ANSI/AAMI 14971
(All Medical Devices)(Programmable Electonic
Devices)
QSR (21 CFR 820)ISO 13485
IEC 62304
Lifecycle Processes, Content Criteria
What is IEC 62304?
1. Specifies activities and tasks for the development and maintenance of software
2. A “how-to” for software compliance
3. What constitutes ‘good’ design output (in conjunction with Guidance)
4. Where is review appropriate
What is IEC 62304?
5. What practices support the quality system and risk management
6. Maps to PMA Guidance7. Designed within context of 13485/QSR and 14971
Impact of IEC 62304
1. Quality System Alterations, Audits2. Document/Template Content Revisions3. Iterative Development Required4. Focus on Risk Management
a) Architectural Decompositionb) Risk Associated with Each Itemc) Safety Class Determines Process
Verification at Every Stage Example: At Unit Level
Verification Process including acceptance criteria Based on Safety Class Costly May affect economics of Tools & Automation
Impact of IEC 62304
Impact of IEC 62304Iterative Development Required
IEC 80002-1, Conclusion
Plan for Risk (Re) Evaluations Plan for Requirement, Design,
Implementation, and Test Updates as a Result
Risk Management: Architectural Decomposition
Class A, B, C ~ LOC Minor, Moderate, MajorIndependence Rationale Required
Impact of IEC 62304
Underlying FDA Guidance for Software Design/Development:
• General Principles of Software Validation; Final Guidance for Industry and FDA Staff, January 11, 2002
http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm
Name is deceiving; outlines “good content” for all/most design output “Validation” is based on a preponderance of evidence that good practices were
used.
Underlying FDA Guidance for Software:
Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Device, September 9, 1999
http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm073778.htm
Defines OTS Software What you need to do with OTS as part of Validation and Risk Assessment
FDA Guidance for Networked Medical Applications:
Guidance for Industry, Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software , January 14, 2005
http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm077812.htm
Risk considerations for networked devices – vulnerable to altered behavior Plan for control of the “device”, updates/patches
Drives requirements for client/mobile devices (e.g. control of OS updates) Drives requirements for web services, including database maintenance
Subject to Validation – Design, not usually Clinical Not usually subject to resubmission
When no impact on indication, efficacy and safety
Types of Potential Risks & Causes Unique to Web/Networked Systems:
Safety/Efficacy Related:Altered Behavior Browser/Server Hijacked Packets Intercepted/Altered
Use Related Delays lead to misuse Lost packets cause errors in judgment
Privacy (HIPPA) Packets Intercepted Phishing
Theft (Intellectual Property) Code transferred to client for execution, especially script Packet Interception
Design Controls and Risk Management Save You Time
Design Controls Help Minimize Defects
Design Controls and Risk Management Save You Time
• Risk Management Makes Sure the 5% Defects Remaining are NOT Hazardous
• Avoids the Exponential Cost Increase for Complete Defect Elimination
(McConnell1)
Design Process Saves You Time
• A Design Process focused on user needs helps insure that the remaining defects do not prevent commercial success.
• Avoids the Exponential Cost Increase for Complete Defect Elimination
(McConnell1)
Contact for more information:Erik HilliardDirector of SalesSterling Medical Devices201-227-7569 x155ehilliard@sterlingmedicaldevices.comwww.sterlingmedicaldevices.com
Medical App Technology InsightsIs your new project a regulated device?
ReferencesStandards:• ANSI/AAMI/IEC 62304:2006, Medical Device Software – Software Life Cycle
Processes
• EN/ISO 14971:2009, Medical Devices – Application of Risk Management to Medical Devices
• IEC/EN 60601-1-4, Medical electrical equipment — Part 1-4: General requirements for safety — Collateral standard: Programmable electrical medical systems (absorbed into 60601-1, ch 14 in latest version)
• EN/ISO 13485:2003, Medical devices - Quality Management Systems – Requirements for Regulatory Purposes