Software in Medical Devices, by MD101 Consulting

Risk management process during design: a sequential process

We've seen that the waterfall development process is the most natural way to implement a software development process compliant with IEC 62304. The description of risk management process in ISO 14971 is also sequential. It is natural for engineers who read the standard to implement it the same way.
This is not a criticism of these standards. Standards must be explicit and articulate to be understood by everybody. Describing steps sequentially is actually the best way to remain explicit and articulate. There are plenty of pitfalls which make this process difficult enough like that. You can imagine how it would be if there were 2 different ways (or more) to do things described in the standards!
Here is a short and simplified description of that process:

1. Identifying risks
2. Assessing risks
3. Defining mitigation actions
4. Assessing risks after mitigation
5. Assessing the overall residual risk
6. Implementing mitigation actions
7. Verifying that mitigation actions are implemented

Note: To keep it simple, I deliberately ignored the iterative steps to identify, assess risks and their mitigations.

Parallel with software development process

This process doesn't lives alone, it is done in conjunction with the software development process. Here is a short reminder of the software development process:

1. Specifications
2. General Conception (or architecture conception)
3. Detailed conception
4. Coding, unit tests, integration
5. Tests, verifications

The diagram below displays the parallel between both processes. Risk activities are in blue letters.

These processes are linked by the data they exchange one another, input data of risk management process are input data of software development process and vice-versa.

Different Intensities of work

Even if both processes work hand in hand, the intensity of work is far from being equivalent in every step. One process has to "wait" that the other process has completed a task before continuing. Like two threads in a computer process!

Risk management: Most of work at the beginning

As it is shown in the diagram, most of work of risk management is done at the beginning of the software development process. The watchdogs in the shrine of ISO 14971 risk management process would even say that identifying, assessing and even defining mitigations shall happen before the beginning of software development. Hence, risk management data are input of software development process.

Software development: Most of work at the beginning ... for architects

The intensity of work of software development process related to risks management is at its maximum for software (or system) architects. As a result, those who deal with identification, assessment and mitigation of risks are architects. Hence mitigation actions are most of times translated in hardware requirements, software requirements, or architecture design.
At the end of general conception, 100% of risks shall have been identified, assessed and mitigated. The overall residual risk shall have been assessed as well. And the traceability between mitigation actions and software requirements/architecture shall be 80%-90% done.

Detailed conception, coding and integration

During these phases, only traceability of mitigations which can be proved by software units in detailed conception are actually linked to risk management. The rest is pure software engineering activities. Developers develop, integrators integrate and architects (or project managers) manage the whole.

Verifications

During these phases, the proofs that mitigations were well implemented are collected. Form the point of view of integrators and testers, the tests cases related to mitigations actions are treated the same way as other tests cases. They verify that what was specified is what the software does.

The diagram below give a synthetic view of the intensity of work of risk management process.

Risk management definitely doesn't have the same pace as software development. But they have to be intertwined to be efficient. Using the waterfall software development process keeps things relatively simple:

• high level design of software is done in parallel with risk management,
• low level design, coding, integration and verification come after and are "only" here to give proofs of mitigation actions.

All of this is very classical. I just refreshed our minds about the interdependence between the two processes. From now on, we don't have anything very useful for agile development. Let's now see risk management during software maintenance.

Risk management process and software maintenance

Maintaining a software placed on the market is a big challenge. No software is perfect, the software manufacturer has to implement a problem resolution process and a software maintenance plan to fix bugs.

Complaints and bugs have an impact on risk assessment report

When bugs are identified internally or received from external sources (mainly customers complaints) the software has to be updated. But, before any software change, the impact of the bug and bug fix on existing risks has to be assessed, and the risks generated by this change has to be assessed as well.
Like software development and risk management during design, software maintenance and risk management after design work in parallel.

Maintenance of risk assessment report

The risk assessment report of software has to be maintained during the whole life of software placed on the market. The steps are, upon any event (complaint, remark...):

• Identifying risks changes (new risks, modified risks)
• Assessing risks changes
• Assessing impacts of risks changes on unchanged risks
• Defining mitigation actions of new/modified risks
• Assessing new/modified risks after mitigation
• Implementing mitigation actions
• Verifying that mitigation actions are implemented
• Verifying that there is no regression on previously implemented mitigation actions
• Assessing the overall residual risks

Maintenance of software

The maintenance of software medical device has to be done with the same level of scrutiny as during design. The documentation has to be updated and the verifications of modifications and their side-effects have to be realized.
Fixing a bug is like back to design, McFly:

1. Updating General Conception (in very rare cases, but it is possible)
2. Updating Detailed conception
3. Modifying Code, adding unit tests, and re-integrating
4. Testing bug fixes and, if necessary side-effects, or even the whole software.

You see that, compared to software design, I removed specifications. If you change specifications you're not maintaining your software, you're creating a new version with, best case, minor functions, or, worst case scenario, a new intended use.

Intensities of work

Like in design where risks are assessed before implementing software, the maintenance of the risk assessment report happens before the implementation of bugs fixes. It can be summarized in the diagram below:

Software maintenance is a bit of design process

As I wrote above, software maintenance is actually like doing a small chunk of design process. Not all steps of design but most of them. That's why the risk assessment report is so subject to changes and has to be updated.
So we know how to deal with small changes in the design of software during its life.
This is not so far from what happens in iterations of agile methods. Changes of design happen in almost every iterations. Starting from what we know about dealing with risk management during software maintenance, we can adapt it to agile methods.
The main difference between iterations and software maintenance is that:

• design changes are big
• they are almost systematic at every iterations.

We'll see that in my next post.