Medical Device and Software Standards

FDA Regulations for Medical Software

Software as a Medical Device (SaMD)

Definition: Software intended for medical purposes that operates on general-purpose computing platforms

Risk Classification: Medical devices are classified by FDA into three classes based on risk:

Class I: Low risk (e.g., elastic bandages)
Class II: Moderate risk (e.g., powered wheelchairs, some clinical software)
Class III: High risk (e.g., implantable pacemakers, life-supporting software)

SaMD Risk Framework: Based on:

Significance of information provided by software
Healthcare situation or condition it addresses

Risk Matrix:

                  Critical  Serious  Non-Serious
Treat/Diagnose       IV        III        II
Drive Clinical Mgmt  III        II        I
Inform Clinical Mgmt  II        I         I

Level I (Lowest Risk): Informing care of non-serious conditions Level IV (Highest Risk): Treating or diagnosing critical conditions

Regulatory Pathways

510(k) Premarket Notification:

Demonstrates device is “substantially equivalent” to predicate device
Most common pathway for medical software
Required documentation:
- Device description
- Intended use and indications
- Comparison to predicate
- Performance data
- Software documentation (see below)
- Labeling

De Novo Classification:

For novel devices with no suitable predicate
Automatically classified as Class III
Can request down-classification to I or II

Premarket Approval (PMA):

Required for Class III devices
Most stringent pathway
Requires clinical trials
Full scientific review

Software Documentation for 510(k):

Software description (name, version, functions, platforms)
Device hazard analysis
Software requirements specification
Architecture design chart
Development environment description
Verification and validation documentation
Revision level history
Unresolved anomalies
Cybersecurity documentation
For SaMD: Description of data inputs and outputs

FDA Guidance Documents

Key Guidances for Software:

General Wellness: Mobile apps for general wellness (not devices)
Mobile Medical Applications: When mobile apps are medical devices
Clinical Decision Support: When CDS software is/isn’t a device
Software Validation: General principles of software validation
Cybersecurity: Premarket and postmarket cybersecurity
AI/ML: Artificial intelligence and machine learning

21st Century Cures Act Impact: Excludes certain software from device definition:

Administrative support functions
Maintaining/encouraging healthy lifestyle
Electronic patient records (if not active clinical decision support)
Transferring, storing, displaying data
Decision support if intended for healthcare professionals to independently review

AI/ML-Based Software

FDA’s Total Product Lifecycle Approach:

Culture of Quality and Organizational Excellence (CQOE)
Good Machine Learning Practice (GMLP)
Patient-Centered Approach

Predetermined Change Control Plan (PCCP):

Documents anticipated modifications to AI/ML algorithm
Describes methodology for implementing changes
Enables “locked” algorithms vs. “continuously learning” algorithms

Key Considerations:

Training data representativeness
Data management practices
Model transparency and interpretability
Real-world performance monitoring
Version control and update notification
Bias and fairness assessment

IEC 62304 (Medical Device Software Lifecycle)

Purpose: International standard for medical device software development lifecycle Harmonized: Recognized by FDA, EU, and other regulatory bodies

Software Safety Classification

Class A: No injury or damage to health possible Class B: Non-serious injury possible Class C: Death or serious injury possible

Impact on Development: Higher classes require more rigorous processes and documentation.

Lifecycle Processes

1. Software Development Process:

Development planning
Requirements analysis
Architectural design
Detailed design
Unit implementation and verification
Integration and integration testing
System testing
Software release

2. Software Maintenance Process:

Problem analysis
Modification implementation
Maintenance review and acceptance
Migration
Software retirement

3. Software Risk Management Process:

Analysis of software contributing to hazardous situations
Risk control measures
Verification of risk control
Risk management file

4. Software Configuration Management Process:

Configuration identification
Change control
Configuration status accounting

5. Software Problem Resolution Process:

Problem identification
Problem analysis
Problem resolution
Trend analysis

Software Development Plan (SDP)

Required Contents:

Software development lifecycle model
Deliverables
Activities and tasks
Software verification approach
Software risk management approach
Documentation
Configuration management
Problem resolution
Supporting tools and environment
References to other plans

Requirements Analysis

Requirements must specify:

Functional and capability requirements
Software system inputs and outputs
Interface requirements between software items
Software-driven alarms, warnings, messages
Security requirements (including data integrity)
Usability requirements
Data definition and database requirements
Installation and acceptance requirements
Operational and maintenance requirements
User maintenance requirements
Regulatory requirements
Risk control measures

Requirements Documentation:

Traceable to system requirements
No contradiction between requirements
Analyzable for correctness
Testable or able to support acceptance criteria

Architecture Design

Must address:

Software items (modules, components)
External interfaces
Internal interfaces
Functional and performance requirements of SOUP (Software of Unknown Provenance)
Data flow and control flow
Hardware and operating system interfaces

Verification and Validation

Verification: “Are we building the product right?”

Requirements verification
Architecture verification
Detailed design verification
Code review
Unit testing
Integration testing
System testing

Validation: “Are we building the right product?”

Conducted on final product in intended environment
Must demonstrate software meets user needs and intended uses
Includes all software requirements

Documentation Requirements

Class A: Minimal documentation Class B: Moderate documentation Class C: Comprehensive documentation including:

Software Development Plan
Software Requirements Specification
Software Architecture Document
Software Detailed Design Document
Verification and Validation Plans and Reports
Risk Management File
Configuration Management Plan
Problem Resolution Records
Software Release Documentation

SOUP (Software of Unknown Provenance)

Definition: Software item already developed and generally available for which adequate records of development process are not available

Examples:

Open-source libraries
Commercial off-the-shelf (COTS) software
Third-party components

Requirements for SOUP:

Identify functional and performance requirements
Document known anomalies
Specify required hardware and software
Verify SOUP meets requirements
Monitor published anomalies
Have plan for end-of-support

ISO 13485 (Medical Device Quality Management)

Purpose: Quality management system requirements for medical device organizations Relationship to IEC 62304: Provides quality system context for software development

Key Requirements

Management Responsibility:

Quality policy
Planning (quality objectives, management review)
Management representative
Internal communication

Resource Management:

Provision of resources
Human resources (competence, training)
Infrastructure
Work environment and contamination control

Product Realization:

Planning
Customer-related processes
Design and development (for software: follows IEC 62304)
Purchasing
Production and service provision
Control of monitoring and measuring equipment

Measurement, Analysis, Improvement:

Monitoring and measurement
Internal audit
Control of nonconforming product
Data analysis
Improvement (corrective and preventive action)

Risk Management per ISO 14971

Risk Management Process:

Risk analysis
- Intended use and reasonably foreseeable misuse
- Hazard identification
- Risk estimation for each hazardous situation
Risk evaluation
- Compare estimated risks to criteria
Risk control
- Risk control option analysis
- Implementation
- Residual risk evaluation
- Risk-benefit analysis
Overall residual risk acceptability
Risk management report
Post-production information
- Production and post-production monitoring
- Review of risk management

Software-Specific Hazards:

Incorrect output or result
Delayed output or result
Incorrect diagnosis or treatment
Incorrect data displayed to user
Software failure or crash
Loss or corruption of data
Cybersecurity vulnerabilities
Interoperability issues

Software Validation

FDA Guidance Principles:

1. Software Development Lifecycle (SDLC): Select appropriate SDLC model (Waterfall, Agile, V-Model, etc.)

2. Requirements Management:

Establish, document, and maintain software requirements
Trace requirements through design, implementation, testing

3. Design:

Document software architecture
Perform design reviews
Verify design against requirements

4. Construction:

Follow coding standards
Conduct code reviews
Perform unit testing

5. Testing:

Develop test plans and protocols
Execute tests and document results
Perform regression testing for changes

6. Maintenance:

Manage software changes
Maintain software configuration
Monitor and report software problems

Validation Documentation:

Validation Plan
Requirements Traceability Matrix
Design documentation
Code documentation
Test Protocols and Reports
Validation Summary Report

Test Coverage: Must demonstrate software requirements are met through:

Normal operation testing
Boundary value testing
Stress testing
Error handling testing
Usability testing (human factors)
Security testing
Installation and upgrade testing

Cybersecurity for Medical Devices

FDA Premarket Guidance:

Security Architecture:

Authentication and authorization
Cryptography
Code signing and update mechanisms
Secure communications
Data protection (at rest and in transit)
Audit logging

Threat Modeling:

Identify assets (data, functions, connectivity)
Identify threat actors and attack vectors
Assess likelihood and impact
Document security controls

Software Bill of Materials (SBOM):

List of all software components
Version information
Known vulnerabilities
Patch status

Security Updates:

Mechanism for delivering updates
Authentication of updates
Testing of updates
User notification

FDA Postmarket Guidance:

Routine Updates:

Security patch management
Vulnerability monitoring
Penetration testing (periodically)

Incident Response:

Vulnerability disclosure program
Incident handling procedures
Communication with FDA and affected users
Root cause analysis

Medical Device Safety Report (MDR): Report to FDA within 30 days of learning about events requiring corrective action to prevent:

Death or serious injury
Malfunction that would likely cause death or serious injury

Cybersecurity-Related Recalls: FDA may classify cybersecurity vulnerabilities as Class I, II, or III recalls based on risk.

Pre-Cert Program (Digital Health Software Precertification)

Status: Pilot program by FDA Goal: Streamline regulatory oversight for software developers

Concept:

Shift focus from product-by-product review to developer assessment
Evaluate organizational excellence and culture of quality
Precertified organizations may have streamlined premarket reviews

Excellence Appraisal: Assess five areas:

Product quality
Patient safety
Clinical responsibility
Cybersecurity responsibility
Proactive culture

Potential Benefits:

Faster time to market
Less burdensome premarket submissions
Ongoing relationship with FDA
Real-world performance monitoring

Requirements:

Real-World Performance data collection and reporting
Transparency in changes and performance

Quiz: Medical Device and Software Standards

Question 1 of 5