Change Request
Summary
The Change Request is a formal document used to initiate changes to already released medical device products. It serves as the starting point for your change management process, requiring review and approval from quality, product, and business teams before implementation.
Why is Change Request important?
Change requests provide structured control over modifications to your medical device after market release. They ensure that all proposed changes are properly evaluated for their impact on safety, effectiveness, and regulatory compliance before implementation. This systematic approach prevents uncontrolled changes that could compromise device performance or introduce new risks, while maintaining traceability for regulatory authorities and supporting your quality management system.
Regulatory Context
Under 21 CFR Part 820 (Quality System Regulation):
- Design changes require design controls under Section 820.30(i)
- Change control procedures must be established and maintained
- Management approval required for design changes (820.30(i))
- Changes must be documented and verified/validated as appropriate
- Risk analysis must be updated for changes affecting safety or effectiveness
Special attention required for:
- Changes that may require FDA notification or new 510(k) submission
- Software changes that affect device classification or predicate comparison
- Changes impacting labeling, intended use, or contraindications
- Modifications that could affect substantial equivalence determination
Under 21 CFR Part 820 (Quality System Regulation):
- Design changes require design controls under Section 820.30(i)
- Change control procedures must be established and maintained
- Management approval required for design changes (820.30(i))
- Changes must be documented and verified/validated as appropriate
- Risk analysis must be updated for changes affecting safety or effectiveness
Special attention required for:
- Changes that may require FDA notification or new 510(k) submission
- Software changes that affect device classification or predicate comparison
- Changes impacting labeling, intended use, or contraindications
- Modifications that could affect substantial equivalence determination
Under EU MDR 2017/745:
- Significant changes require notified body notification under Article 120
- Changes must be evaluated against general safety and performance requirements
- Quality management system must control all changes (Article 10(9))
- Technical documentation must be updated to reflect changes (Annex II)
- Post-market surveillance data must inform change decisions
Special attention required for:
- Assessment of change significance under Article 120 criteria
- EUDAMED registration updates for device modifications
- CE marking validity after significant changes
- Clinical evaluation updates for changes affecting safety or performance
Guide
Initiating Change Requests
Identify the source of your change request clearly. Changes can originate from customer complaints, new feature requirements, problem reports, clinical evaluation findings, post-market surveillance data, or internal team identification. Each source type may require different levels of documentation and evaluation, so accurate categorization is essential.
Document the change comprehensively by describing what will be added, removed, or modified. Provide sufficient detail for reviewers to understand the scope and implications of the proposed change. Include the rationale for why the change is necessary and any supporting data or evidence.
Impact Assessment
Identify affected products and versions systematically. Create a clear table showing which product variants and software versions will be impacted by the change. This information is crucial for determining the scope of testing, documentation updates, and regulatory notifications required.
Evaluate software item impacts when your device includes software components. Use your existing software architecture documentation to identify which software items will be affected and which will remain unchanged. This analysis helps scope the technical implementation and testing requirements.
Documentation and Process Impact Analysis
Assess documentation impacts by reviewing your existing document library against the proposed change. Consider whether the change will affect your intended use, device classification, user needs, risk management file, system requirements, design documentation, testing protocols, clinical evaluation, or labeling materials.
Anticipate process changes that may be required. Some changes may necessitate updates to your manufacturing processes, quality procedures, or post-market surveillance activities. Early identification of these impacts helps ensure comprehensive change planning.
Team Responsibilities and Review
Engage appropriate teams in the review process. The product team evaluates technical feasibility and necessity, the quality team assesses regulatory and documentation impacts, and the business team considers commercial and operational implications. Each team brings essential expertise to the change evaluation process.
Ensure proper approval before proceeding with implementation. The change request serves as a gate that prevents unauthorized modifications while ensuring that all stakeholders understand and agree with the proposed changes.
Integration with Change Management Process
Connect to your broader change management system by referencing your Change Management SOP. Ensure that approved change requests trigger the appropriate downstream activities, including change evaluation reports, updated documentation, and verification testing.
Example
Scenario
Your cardiac monitoring mobile app currently displays heart rate data in beats per minute (BPM) only. Based on customer feedback and clinical evaluation findings, you want to add heart rate variability (HRV) analysis and display capabilities. This change would involve new algorithms, additional user interface elements, and expanded data storage requirements.
Change Request Document
Source of Change Request: Clinical Evaluation or Post-Market Surveillance
Description of Change: Add heart rate variability (HRV) analysis and display functionality to the cardiac monitoring mobile application. This enhancement will include:
- Implementation of time-domain HRV analysis algorithms (RMSSD, pNN50, SDNN)
- New user interface screens for HRV data visualization
- Additional data storage requirements for HRV metrics
- Updated export functionality to include HRV data in reports
- Enhanced user manual and help documentation
The change is driven by clinical feedback indicating that HRV data would provide additional value for patient monitoring and healthcare provider decision-making.
Affected Products and Versions:
| Product Name(s) | Version(s) |
|---|---|
| CardioTracker Mobile App | v3.2.0 and later |
| CardioTracker Web Dashboard | v2.1.0 and later |
Affected Software Items:
| Software Item | Affected by Change (Yes/No) | Comments |
|---|---|---|
| Data Acquisition Module | Yes | Must capture additional R-R interval data |
| Signal Processing Engine | Yes | New HRV calculation algorithms required |
| User Interface Components | Yes | New screens and data visualization elements |
| Data Storage Layer | Yes | Additional database fields for HRV metrics |
| Export/Reporting Module | Yes | Include HRV data in generated reports |
| Authentication System | No | No changes to user login or security |
| Cloud Sync Service | Yes | Sync HRV data across devices |
Anticipated Impacts of Change:
| Document / Process | Update Anticipated | Comments |
|---|---|---|
| Intended Use | Yes | Expand to include HRV monitoring capabilities |
| Device Classification | No | Remains Class II medical device software |
| User Needs list | Yes | Add user needs related to HRV analysis |
| Risk Management File | Yes | Assess risks of HRV algorithm accuracy |
| System Requirements | Yes | New functional requirements for HRV features |
| Subsystem Requirements | Yes | Algorithm performance and accuracy specs |
| Product Design / Architecture | Yes | Software architecture updates for new modules |
| Verification or Validation Testing | Yes | New test protocols for HRV functionality |
| Usability Testing | Yes | Test new user interface elements |
| Clinical Evaluation | Yes | Evaluate clinical utility of HRV features |
| Labeling or Informational Materials | Yes | Update user manual and marketing materials |
Team Responsibilities
Product / Software Team: Responsible for determining technical feasibility of HRV implementation, estimating development effort, and identifying affected software components. Will assist in defining new system requirements and architecture changes.
Quality Team: Responsible for reviewing regulatory implications of adding HRV functionality, determining impact on device classification, and identifying all documentation requiring updates. Will ensure change aligns with quality management system requirements.
Business Team: Responsible for evaluating commercial impact, resource allocation, and timeline considerations. Will assess market demand and competitive positioning for HRV features.