How do I document changes and bug fixes in a compliant manner?
IEC 62304 §6 (maintenance) · §8 (configuration management) · §9 (problem resolution)
The short answer
All changes to medical device software — including bug fixes — must go through a documented change control process. IEC 62304 §6 governs software maintenance, §8 governs configuration management, and §9 governs problem resolution. Undocumented bug fixes are a guaranteed audit finding.
Change types and how they are handled
| Change type | Process |
|---|---|
| Planned enhancement (new feature) | Full software development lifecycle: requirements → architecture → implementation → verification → release |
| Problem resolution (bug fix) | Problem Report → impact analysis → fix → regression testing → release records |
| Emergency fix (critical production issue) | Same process as bug fix — same documentation required; compressed timeline does not remove the requirement |
| SOUP update (third-party library upgrade) | SOUP register update → anomaly re-evaluation → impact analysis → regression testing → release records |
Required change documentation
- Problem Report / Change Request: Identifies the issue or change; unique ID; description; date raised; priority/severity
- Impact analysis: Does this change affect safety? Does it change the software safety class? Does it affect other software items? Does it require a significance assessment under MDCG 2020-3?
- Implementation records: What was changed; which software items were modified; code review records (Class B/C)
- Verification/regression test evidence: Tests run; test results; evidence that the fix works and did not introduce new issues
- Updated release records: New version number; what was included in this release; who approved
- Updated traceability matrix: If requirements changed, the traceability matrix must be updated to reflect the change
Problem Resolution Records (§9)
Problem resolution records are required for all software safety classes. The minimum content for each problem record is:
- Unique problem record identifier
- Description of the problem
- Date the problem was identified
- Current status (open / in progress / resolved / deferred)
- Resolution description
For Class B and C, additional content is expected: severity assessment, root cause analysis, and evidence of testing that the resolution is effective. A resolution that says "fixed" without root cause is insufficient for Class C.
Configuration management (§8)
Configuration management provides the backbone for change control. Key requirements:
- All software items, SOUP versions, and build configurations under version control
- Ability to reproduce any released build from the configuration baseline
- Release baseline documentation — exactly what version of what was released
- Change control records linked to the configuration items that changed
Emergency fixes
Emergency fixes for critical production issues are subject to the same documentation requirements as any other change. In practice, the timeline is compressed — the fix may be deployed before all documentation is complete — but the documentation must be completed after the fact, and the process must be defined in your Software Development Plan.
An emergency fix without an impact analysis is a nonconformity, even if the fix was technically correct. Do not skip the impact analysis — document it retrospectively if needed, but document it.
Frequently asked questions
What is the difference between a hotfix, patch, and minor release?
IEC 62304 does not define these terms — they are internal versioning conventions. What matters is that every change, regardless of how it is versioned, goes through the documented change control process. Whether you call it a hotfix or a patch, it requires a problem record, impact analysis, verification evidence, and release records.
Does every bug need a formal Change Request?
Yes — every bug fix (problem resolution) requires a problem record. In practice, this is typically a ticket in your issue tracker (Jira, GitHub Issues, etc.) with the required fields populated. The problem record does not need to be a formal paper document — electronic records are fine.
Can GitHub commits serve as change records?
Git commit history can supplement change records but does not replace them. Commits do not capture impact analysis, severity assessment, or verification results. A combination of issue tracker records (problem records) linked to pull requests (implementation records) with CI test evidence (verification records) and a release tag (release records) can together satisfy the requirements.
What version numbering convention should I use?
IEC 62304 does not specify a version numbering convention. Semantic versioning (major.minor.patch) is widely used and practical. What matters is that the version number is unique, traceable to a specific configuration baseline, and used consistently in documentation, labels, and EUDAMED/UDI records.