SOP Software Development

​

Summary

This Standard Operating Procedure (SOP) defines the comprehensive integrated software development lifecycle for medical device software products. It establishes a systematic approach following IEC 62304 standards to ensure software safety, effectiveness, and regulatory compliance through defined stages from specification to release, incorporating risk management, usability engineering, and change control throughout the development process.

​

Why is SOP Software Development important?

Software development in medical devices requires rigorous control because software failures can directly impact patient safety and device effectiveness. Unlike traditional software development, medical device software must follow validated development processes that demonstrate safety and effectiveness through each stage of the lifecycle.

This SOP is critical because it integrates multiple regulatory requirements into a cohesive development process. IEC 62304 mandates specific development activities based on software safety classification, while FDA and EU regulations require design controls, risk management, and usability engineering. Without a structured approach, your development process may miss critical safety requirements, fail regulatory inspections, or produce software that cannot be validated for medical use.

The integrated approach ensures that risk management, usability considerations, and verification activities occur throughout development rather than as afterthoughts, significantly improving software quality and reducing development risks.

​

Regulatory Context

​

Guide

​

Understanding the Five-Stage Development Process

Stage-based development ensures systematic progression from requirements through release while maintaining regulatory compliance. Each stage has specific entry criteria, activities, and exit criteria that must be satisfied before proceeding.

Stage 1 (Specification) establishes the foundation with user needs, software requirements, risk management planning, and safety classification. This stage defines what the software must accomplish and how safely it must operate.

Stage 2 (Design and Development) creates the software architecture, implements code, and conducts verification testing. This stage addresses how the software will meet requirements while maintaining safety and performance.

Stage 3 (Testing) performs system-level verification to ensure all requirements are properly implemented. Integration testing and anomaly identification occur during this critical validation stage.

Stage 4 (Validation) confirms that the software meets user needs through usability evaluation and, for IVD software, performance evaluation studies. This stage demonstrates fitness for intended use.

Stage 5 (Release) finalizes documentation, conducts regulatory submissions, and prepares for market deployment with appropriate labeling and instructions for use.

​

Implementing Risk-Based Development Approaches

Software safety classification drives development rigor throughout the process. Class A software (no contribution to hazardous situations) requires basic documentation and testing. Class B software (contributes to non-serious injury) needs moderate rigor with defined architecture and verification. Class C software (contributes to death or serious injury) demands comprehensive documentation, detailed design, and extensive testing.

Risk management integration occurs throughout all stages, not just at the beginning. Continuously evaluate how development decisions affect risk levels, update risk assessments when new hazards are identified, and ensure risk controls are properly implemented and verified.

Change impact assessment is critical when modifying existing software. Use your change management process to evaluate how modifications affect safety classification, risk levels, verification requirements, and regulatory compliance.

​

Establishing Effective Verification and Validation Strategies

Verification activities demonstrate that software correctly implements requirements. This includes code reviews, unit testing, integration testing, and system testing. The depth of verification must match your software safety classification and complexity.

Unit-level verification ensures individual software components function correctly. Use code reviews for critical algorithms and automated testing for functional verification. Document verification methods and results for regulatory compliance.

System-level testing validates that integrated software meets all requirements. Create comprehensive test plans covering normal operation, error conditions, and boundary cases. Pay special attention to safety-critical functions and user interface elements.

Validation through usability evaluation demonstrates that software meets user needs in realistic conditions. Conduct formative evaluation during development to identify usability issues early, and summative evaluation to confirm safe and effective use.

​

Managing Software Architecture and Design Controls

Software architecture documentation must clearly describe system structure, interfaces, data flow, and safety-critical elements. For Class C software, create detailed design documentation showing how safety requirements are implemented at the code level.

Software of Unknown Provenance (SOUP) requires special attention throughout development. Evaluate SOUP components for safety impact, maintain version control, and assess security vulnerabilities. Document SOUP evaluation and ongoing monitoring procedures.

Traceability maintenance connects user needs through requirements to design elements, code implementation, and test cases. This traceability supports change impact analysis and regulatory compliance demonstration.

​

Integrating Usability Engineering and Performance Evaluation

Usability engineering integration ensures that safety and effectiveness considerations guide user interface design. Identify hazardous use scenarios early in development and design interfaces to prevent use errors.

Critical task identification focuses validation efforts on the most important user interactions. These tasks typically involve safety-critical functions, complex procedures, or error-prone activities that could impact patient safety.

For IVD software, performance evaluation encompasses scientific validity, analytical performance, and clinical performance. Plan these evaluations early in development to ensure appropriate data collection and analysis.

​

Preparing for Regulatory Submissions and Release

Documentation completeness verification ensures all required deliverables are created and approved before release. Use release checklists to confirm that development, verification, validation, and regulatory requirements are satisfied.

Regulatory submission preparation varies by jurisdiction and device classification. Ensure appropriate 510(k), PMA, or CE marking submissions are prepared with complete software documentation.

Post-market surveillance integration establishes processes for collecting and analyzing software performance data after release. Plan how user feedback, software problems, and performance monitoring will inform future development cycles.

​

Example

​

Scenario

You’re developing a Class B medical device software application that calculates medication dosages based on patient parameters. The software interfaces with hospital information systems and displays recommendations to healthcare providers. Here’s how the five-stage process applies:

Stage 1 - Specification: Define user needs for dosage calculation accuracy, patient safety alerts, and system integration. Establish software requirements including calculation algorithms, user interface specifications, and data validation requirements. Classify as Class B software due to potential for incorrect dosing recommendations. Create risk management plan identifying calculation errors and interface failures as primary hazards.

Stage 2 - Design and Development: Design software architecture with separate modules for data input, calculation algorithms, safety checks, and user interface. Document interfaces with hospital systems and SOUP components used for calculations. Implement code with unit testing for calculation algorithms and integration testing for system interfaces. Conduct code reviews focusing on safety-critical calculation functions.

Stage 3 - Testing: Execute comprehensive system testing covering all calculation scenarios, edge cases, and error conditions. Test integration with simulated hospital systems and verify data validation functions. Document any anomalies in the known anomalies list and address safety-critical issues immediately.

Stage 4 - Validation: Conduct usability evaluation with healthcare providers using realistic clinical scenarios. Focus on critical tasks like dosage calculation review, safety alert recognition, and error recovery procedures. Validate that users can safely and effectively use the software in their clinical environment.

Stage 5 - Release: Complete regulatory submissions (510(k) for FDA, technical file for EU), finalize labeling and instructions for use, and prepare post-market surveillance plan. Ensure all documentation is approved and release checklist is completed before deployment.

​

Example Development Documentation

Software Requirements Specification:

• REQ-001: Calculate pediatric medication doses based on weight with accuracy ±2%
• REQ-002: Display safety alerts when calculated dose exceeds maximum recommended
• REQ-003: Integrate with hospital EMR systems via HL7 FHIR interface
• REQ-004: Validate all patient data inputs before calculation processing

Risk Assessment Integration:

• Risk ID R-001: Incorrect dose calculation due to algorithm error → Implement dual calculation verification
• Risk ID R-002: Interface failure causing data corruption → Add data validation and error detection
• Risk ID R-003: User interface confusion leading to wrong dose selection → Usability testing and interface optimization

Stage Gate Reviews:

• Stage 1 Review: Requirements approved, risk management plan established, safety classification confirmed
• Stage 2 Review: Architecture verified, code reviews completed, unit testing passed
• Stage 3 Review: System testing successful, known anomalies documented and acceptable
• Stage 4 Review: Usability evaluation completed, validation criteria met
• Stage 5 Review: All documentation complete, regulatory submissions ready, release criteria satisfied

​

Q&A