IEC 62304 Medical device – Software life cycle

Summary and explanation on IEC 62304 Medical device – Software life cycle.

1. Scope of IEC 62304 Medical device – Software life cycle

Development and maintenance of medical device software:

• When software is itself a medical device or,
• when software is an embedded or integral part of the final medical device.

2. Normative reference

This article is to be read in the framework of a risk management process according to ISO 14971 that should be implemented.

3. Terms and definitions

• System: your software + the external software + the hardware around.
• Software system: your software (embedded in a MD or standalone).
• Software element: the breakdown of your software into large, medium and small pieces (deconstruction into µ-controller, libraries, source files, functions…).
• Software unit: the smaller pieces resulting from the breakdown. You decide the size. The granularity should allow for comprehensive verification of the code.
• SOUP (Software of Unknown Provenance): the third-party softs you use (libraries, drivers…) but for which you have no evidence of performance.

4. General requirements

Ideally, you should have a quality system ISO 13485 to prove that you can handle approximately of 2/3 critical issues (post-market surveillance, traceability, design & development process…)

As stated below, ISO 14971 is also relevant.

Software class

The rules change with the amendment. In summary:

• Class A if the software induces or controls an acceptable risk
• Class B or C otherwise, depending on the level of severity.

The probability of a bug must be 100% before implementation of the standard.

We can imagine a more refined approach, taking into account two probabilities:

1. probability of having the bug that induces the dangerous situation (100%) and
2. probability of having the dangerous situation and the harm (not necessarily 100%), we then have :

In addition:

• If some soft is used to control a risk: the soft retrieves the class associated with the harm.
• A subpart of the code retrieves the class from the parent code unless separation is demonstrated:

5. Development

At each stage of the V-cycle:

1. Make a plan.
2. Make a review of the plan.
3. Apply the plan.
4. Make a review of the results.

V-cycle

The development cycle template and the applicability based on classes are summarized in this diagram:

• Development plan: who, when, how, what tools… and the planning of required activities according to the class.
• Software specification: identify the requirements well and think about the tests that will be done behind them (this is the time to start imagining them). If it is precise enough: the “project” specifications can act as the requirement’s specification.
• Architecture : the dispatching of software functions into different software items, broken down to software units. A well-designed architecture allows isolating the critical functions (the high classes) in code/microcontrollers well separated from the rest of the software (to be demonstrated). As a result, the documentation effort is limited. Here also one can imagine the tests to be done behind (integration and non-regression).
• Detailed design: we detail as much as possible down to the lowest level functions, always keeping in mind that we will have to test.

You can now code.

Come the tests:

• Unit tests of the software units.
• Integration and integration and non-regression testing.
• Functional tests.

You can now deliver (there is still some doc to generate, see §8)

6. Software maintenance

Concerns the changes you will make after delivery (bug fixes and adding/changing functions according to feedback from the field, the customer, the marketing service…)

• Document feedback requesting/requiring a change to the software, your post-market surveillance process is there for that.
• Evaluate if a change is needed (remember: if there is a patient risk the answer is yes), make a change request if necessary.
• Evaluate the Request For Change (hint: analyze the risks).
• If change accepted: return to Development case with a new functional requirement to implement.
• Inform your customers/your NB/your competent authority, depending on the change.
• Release.
• Monitor.

A maintenance plan should explain all this.

7. Risk management

Use the ISO 14971 taking into account the SOUP (to be validated. Monitor updates, change logs, bug reports…), other elements of the system (hardware and external software), misuse (refer to 62366-1)…

8. Configuration Management

You are asked to keep the necessary and sufficient to be able to replay development and testing: software configuration, test data, hardware configuration… are to be identified and archived.

A configuration management plan should explain all this.

9. Troubleshooting

(Process for fixing bugs)

• To be started during development (first bugs are highlighted during initial testing).
• If the bug is discovered during development: it is handled by the development team, using the tools in the development plan (typically: a ticket manager)
• If bug after release: launch the maintenance process.
• Code a patch, implement changes, verify: return to Design & Development.