Software Development and Maintenance Plan

​

Summary

The Software Development and Maintenance Plan establishes your systematic approach to creating compliant medical device software, defining the complete lifecycle from requirements through development, testing, and post-market maintenance according to IEC 62304 and regulatory standards.

​

Why is a Software Development and Maintenance Plan Important?

A comprehensive Software Development and Maintenance Plan provides the regulatory foundation for medical device software development. Without this structured framework, software development becomes chaotic and unpredictable, leading to documentation gaps, missed safety requirements, and regulatory compliance failures that can prevent market approval.

This plan transforms abstract regulatory requirements into concrete development activities that your team can follow. It establishes critical processes like risk-based development, configuration management, and verification activities that ensure your software meets both user needs and safety standards. The plan also demonstrates to regulatory authorities that your development process follows recognized standards and best practices.

For medical device software, the plan serves as your roadmap to compliance by defining how you’ll manage software safety classification, handle Software of Unknown Provenance (SOUP), and maintain traceability between requirements and implementation. This structured approach prevents costly rework and ensures your software development activities generate the documentation needed for regulatory submissions.

​

Regulatory Context

​

Guide

Your Software Development and Maintenance Plan must establish a comprehensive framework that addresses all aspects of medical device software development while ensuring regulatory compliance.

​

Planning Foundation

Start by defining your software scope and classification. Identify all software components, their intended use, and determine the IEC 62304 safety classification (Class A, B, or C) based on potential harm from software failure. This classification drives the rigor required for all subsequent development activities.

Establish team responsibilities across functional groups. Software teams handle requirements, architecture, implementation, and testing. Quality teams oversee process compliance, risk management, and release approval. Clinical teams validate user needs and participate in usability evaluation. Document clear interfaces between these groups and their decision-making authorities.

​

Development Methodology

Define your development lifecycle model whether waterfall, agile, or hybrid approaches. For each development stage, specify required activities, inputs, outputs, and review criteria. Medical device software typically follows a stage-gate approach with defined milestones for requirements, design, implementation, verification, and release.

Document design and development stages with clear entry and exit criteria. Stage 1 focuses on planning and requirements. Stage 2 covers architecture and detailed design. Stage 3 handles implementation and unit testing. Stage 4 addresses system verification and validation. Stage 5 manages release preparation and deployment.

​

Configuration Management

Establish robust version control processes using your chosen system (GitHub, GitLab, etc.). Define branching strategies with main, development, feature, and release branches. Implement semantic versioning (MAJOR.MINOR.PATCH) with clear criteria for each change type.

Document change management procedures that categorize changes by impact. Major changes affecting safety or functionality require comprehensive review and may trigger UDI updates. Minor changes need standard verification. Patches for bug fixes follow expedited procedures while maintaining traceability.

​

Risk Management Integration

Integrate risk management activities throughout development. Conduct initial risk assessment during planning, update risks during design changes, implement risk controls through software features, and verify control effectiveness through testing. Maintain traceability between identified risks and implemented controls.

​

Verification and Validation Strategy

Define testing approaches appropriate to your software classification. Class A software requires basic verification. Class B needs comprehensive testing including integration and system testing. Class C demands the most rigorous verification including formal methods where appropriate.

Establish verification activities including code reviews, unit testing, integration testing, and system testing. Document test planning, execution, and results. Define criteria for test pass/fail decisions and procedures for handling defects and anomalies.

​

SOUP Management

Document processes for Software of Unknown Provenance including identification, risk assessment, and ongoing monitoring. Classify SOUP by risk level (low, medium, high) and establish monitoring frequencies. Low-risk SOUP requires review every two years, medium-risk annually, and high-risk every six months.

​

Maintenance and Post-Market Activities

Define post-release maintenance including bug tracking, feature enhancements, security updates, and emergency fixes. Establish procedures for incorporating post-market surveillance feedback and user complaints into software improvements.

​

Example

Scenario: You’re developing a mobile application for stress monitoring that collects physiological data and provides wellness recommendations. The app connects to a wearable device and stores data in the cloud. A software malfunction could lead to incorrect stress level readings, potentially causing user anxiety but no serious physical harm.

​

Software Development and Maintenance Plan

ID: SDMP-StressWear-2024-001

1. Scope

This plan covers the StressWear mobile application (iOS/Android), cloud backend services, and device communication firmware. The software enables stress monitoring through physiological data collection and analysis, classified as IEC 62304 Class B software.

2. Software Classification

StressWear is classified as Class B software under IEC 62304. Software failure could result in incorrect stress readings leading to user anxiety or inappropriate wellness recommendations, but would not cause serious physical injury.

3. Team Responsibilities

• Software Team: Requirements documentation, architecture design, implementation, unit testing, integration testing, SOUP management, release notes
• Quality Team: Process oversight, verification planning, risk management review, release approval, post-market surveillance
• Clinical Team: User needs validation, usability testing, clinical evaluation, user feedback analysis

4. Development Stages

Stage 1 - Planning:

• Activities: User needs specification, software requirements development, risk assessment, architecture planning
• Deliverables: User Needs List, Software Requirements Document, Risk Management Plan, Software Architecture outline
• Review Criteria: Requirements traceability, risk completeness, architecture feasibility

Stage 2 - Design and Implementation:

• Activities: Detailed architecture, code implementation, SOUP identification, unit testing
• Deliverables: Software Architecture Document, SOUP List, implemented code, unit test reports
• Review Criteria: Architecture compliance, code quality standards, SOUP risk assessment

Stage 3 - Verification:

• Activities: Integration testing, system testing, anomaly documentation, usability test planning
• Deliverables: Integration test reports, system test reports, known anomalies list, usability test plan
• Review Criteria: Test coverage adequacy, requirement verification, anomaly acceptability

Stage 4 - Validation:

• Activities: Usability testing, clinical validation, final risk assessment
• Deliverables: Usability evaluation report, clinical validation results, updated risk assessment
• Review Criteria: User acceptance, clinical effectiveness, residual risk acceptability

Stage 5 - Release:

• Activities: Release preparation, final documentation review, deployment planning
• Deliverables: Release notes, release checklist, deployment guide
• Review Criteria: Documentation completeness, release readiness, deployment verification

5. Configuration Management

Version control managed in GitHub with semantic versioning:

• MAJOR (X.0.0): New features affecting device functionality, UDI-DI update required
• MINOR (1.X.0): Feature additions, backward compatible, UDI-PI update
• PATCH (1.1.X): Bug fixes, security updates, no UDI change required

Branching Strategy:

• main: Production releases only
• develop: Integration branch for features
• feature/*: Individual feature development
• hotfix/*: Emergency fixes from main

6. SOUP Management

SOUP components documented with risk classification:

• React Native (Medium Risk): Core framework, annual security review
• AWS SDK (Low Risk): Cloud services, biannual review
• Encryption Libraries (High Risk): Security critical, quarterly review

7. Verification Activities

• Code Review: All code reviewed by team member not involved in implementation
• Unit Testing: Minimum 80% code coverage for critical functions
• Integration Testing: API interfaces, device communication, data flow
• System Testing: End-to-end scenarios, performance, security
• Usability Testing: Task completion, error recovery, user satisfaction

8. Risk Management

Risk assessment updated at each stage with focus on:

• Data accuracy and reliability
• User interface clarity and error prevention
• Cybersecurity and data protection
• Device communication reliability
• Cloud service availability

9. Maintenance Procedures

• Bug Reports: Tracked in GitHub Issues with severity classification
• Security Updates: Emergency process for critical vulnerabilities
• Feature Requests: Evaluated through change control process
• Post-Market Feedback: Integrated into quarterly software reviews

​

Q&A