Early access registrations are open for Headstart, a predictable, fixed-price program for becoming compliant.

Updated April 30, 2021

Template: SOP Change Management

Dr. Oliver Eidel
IEC 62304

This is a free template, provided by OpenRegulatory.

A preview of the template is shown below. You can download it as Word (.docx), PDF or markdown file.

The template license applies (don't remove the copyright at the bottom).

Download as:
Beginning of template

SOP Change Management

Classes IEC 62304:2006 Section Document Section
A, B, C 6.2.3 2
A, B, C 6.2.4 2
A, B, C 6.2.5 2
A, B, C 6.3.1 3
A, B, C 6.3.2 3
A, B, C 7.4.1 2
B, C 7.4.2 2
B, C 7.4.3 2
A, B, C 8.2.1 2
A, B, C 8.2.2 3
A, B, C 8.2.3 3
A, B, C 8.2.4 3
A, B, C 9.4 (All)

Summary

This SOP describes how we evaluate and make changes to our software after it’s released.

General Considerations

Feedback Classification

Feedback is either classified as bug fix or regular change request:

Guidance Documents

The processing of changes is based on the following regulatory provisions and guidances:

Process Steps

1. Creation of Change Request

Changes proposals can originate from various sources, e.g.:

They can originate from anywhere inside the company.

The Product Manager creates a change request ticket in the company’s project management software with a description of the proposed change.

Participants
Anyone in the company with a change proposal
Input Output
Change proposal Documented change request (ID per product version)

2. Evaluation of Change

The Product Manager, together with a Regulatory Affairs Manager and the Head of Software Development, then evaluates the proposed change. In a first step, it is assessed if the change constitutes a bug fix or not. In case of a bug fix, the Product Manager directly proceeds with the evaluation as part of the bug fixes documentation list (link here).

If the change does not constitute a bug fix but rather a regular change request, it is evaluated whether the change:

  1. Is a substantial change (refer to e.g. MDCG 2020-03 for guidance)
  2. Introduces any new risks and whether those are acceptable
  3. Impacts any existing risk control measures
  4. Is technically feasible
  5. Makes sense for the product strategy of the company

The evaluation results in a decision whether the change is implemented and whether the notified body needs to be involved if the change is substantial. These two decisions are documented in the change request ticket.

Multiple proposed changes can be batched and discussed in one session.

Participants
Product Manager
Head of Software Development
Regulatory Affairs Manager
Input Output
Change request Completed change evaluation

3. Implementation, Verification, Validation, Update of Documentation

Change requests result as input to the SOP Software Development and are implemented accordingly.

This includes verification, validation and release activities while ensuring traceability. The relevant documentation is updated and released with an updated declaration of conformity.


Template Copyright openregulatory.com. See template license.

Please don’t remove this notice even if you’ve modified contents of this template.

End of template

Questions?

Regulatory compliance is not rocket science.

But finding a good consultant is.

No Cookie For You Privacy Policy Imprint
No QMS on this planet will save you from creating crappy software.