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