Design and Development Plans
Software Development and Maintenance Plan
Structure comprehensive software lifecycle processes ensuring safety classification compliance and systematic development.
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
Under 21 CFR Part 820.30 (Design Controls), the FDA requires:
- Documented development planning that describes design activities and responsibilities
- Software lifecycle processes following recognized consensus standards like IEC 62304
- Risk-based approach to software development with appropriate verification activities
- Configuration management and change control processes
- Design History File (DHF) documentation for all development activities
- Software safety classification (Class A, B, or C)
- Risk management integration throughout development
- SOUP management and evaluation
- Verification and validation appropriate to safety class
Special attention required for:
- Software safety classification accuracy - misclassification can lead to inadequate development rigor
- SOUP vulnerability management and ongoing monitoring
- Cybersecurity considerations per FDA guidance on medical device cybersecurity
- Software Bill of Materials (SBOM) for transparency in software components
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
- 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
- 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
- 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
- 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
- Activities: Release preparation, final documentation review, deployment planning
- Deliverables: Release notes, release checklist, deployment guide
- Review Criteria: Documentation completeness, release readiness, deployment verification
- 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
- main: Production releases only
- develop: Integration branch for features
- feature/*: Individual feature development
- hotfix/*: Emergency fixes from main
- 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
- 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
- Data accuracy and reliability
- User interface clarity and error prevention
- Cybersecurity and data protection
- Device communication reliability
- Cloud service availability
- 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
How do I determine the correct IEC 62304 software classification for my device?
How do I determine the correct IEC 62304 software classification for my device?
Software classification depends on the potential harm from software failure. Class A means no injury or damage possible (e.g., administrative software). Class B indicates non-serious injury possible (e.g., monitoring apps that could cause anxiety). Class C means death or serious injury possible (e.g., insulin dosing software). Consider the worst-case scenario if your software fails completely or provides incorrect information. When in doubt, choose the higher classification for additional safety margin.
What level of detail should I include for SOUP components in my plan?
What level of detail should I include for SOUP components in my plan?
Document all SOUP components with their name, version, source, and functional purpose. Include risk classification based on potential impact if the SOUP fails. For each SOUP item, specify verification approach, known anomalies, and monitoring frequency. High-risk SOUP requires quarterly review, medium-risk annual review, and low-risk biannual review. Maintain a SOUP list as a living document updated with each software release.
How do I handle agile development within the IEC 62304 framework?
How do I handle agile development within the IEC 62304 framework?
IEC 62304 is compatible with agile methodologies when properly structured. Map agile activities to IEC 62304 requirements - user stories become software requirements, sprints align with development activities, and retrospectives support continuous improvement. Maintain documentation incrementally rather than at the end. Use automated testing and continuous integration to support verification activities. Ensure each sprint produces appropriate documentation and that design reviews occur at logical intervals.
What documentation must be maintained throughout the software lifecycle?
What documentation must be maintained throughout the software lifecycle?
Maintain software requirements, architecture documentation, verification results, risk management records, and change history. For Class B and C software, add detailed design documentation and comprehensive test records. All documentation must be version-controlled and traceable. Keep records of design decisions, review outcomes, and rationale for changes. Documentation should be sufficient to demonstrate compliance during regulatory inspections.
How do I manage software changes after market release?
How do I manage software changes after market release?
Establish a change control process that evaluates each change for regulatory impact. Minor changes like bug fixes may require minimal documentation. Major changes affecting safety or functionality need comprehensive review including risk assessment updates, verification testing, and potential regulatory notification. Maintain change logs, assess cumulative impact of multiple changes, and ensure post-market surveillance data informs change decisions. Some changes may require notified body notification or new regulatory submissions.
What verification activities are required for different software classifications?
What verification activities are required for different software classifications?
Class A software requires basic verification that software requirements are met. Class B software needs comprehensive verification including unit testing, integration testing, and system testing with documented procedures and results. Class C software demands the most rigorous verification including formal methods where appropriate, comprehensive testing at all levels, and additional verification of safety-related functions. Higher classifications require more detailed documentation and independent review of verification activities.