How to deal with ISO 14971 in a software company?
By Mitch on Friday, 19 October 2012, 04:32 - Standards - Permalink
Let's continue a former post about dealing with ISO 13485 in a software company. ISO 13485 and ISO 14971 are a bit like sister standards. You can't implement one without the other!
But how to deal with ISO 14971 in a software company, actually?
Short answer
The short answer is quite simple:
Like any other medical device company.
The process described in ISO 14971 shall not work in fail-soft mode. Unlike ISO 13485 standard, there is no possible exclusion.
Long answer
The ISO 14971 standard describes a risk management process that medical devices manufacturers have to apply. When manufacturers design devices that embed software or are standalone software, a few peculiarities of software have to be integrated in the risk management process.
That doesn’t mean that the ISO 14071 process has to be tweaked but that additional concepts and activities, mainly described in IEC 62304 standard, have to be implemented.
The schema below represents the ISO 14971 risk management process as an area. Activities of software (and other technical fields) can be seen as addendum to a main generic risk management process.
Risks in software
The main reason of this situation is the difference in the causes and consequences of hazardous situations, and in the way they are detected, when software failure occurs. See for example my previous articles about risks, defects and software failures.
The second main reason is the fact that mitigation actions are made by design. One could argue this is also the case for hardware. But hazardous situations also happen because hardware wears, ages and breaks. Mitigations actions for hardware may be replacing aging parts. This is not the case of software. So design is the only way to mitigate risks (except some maintenance actions like archiving data; or warnings in instructions for use, known to be of lesser efficiency).
Risk management in design
The graph below shows that the risk management process during design has to be realized in parallel with the software development process.
The risk assessment report is continuously updated during the software development process.
Adapt risk management process
One possible solution for manufacturers that design both hardware and software is to separate the risk management process in two parts, one for hardware and one for software. The part about software could be a work instruction that adds specific tasks to the main risk management procedure.
That software-related part should contain activities required by the IEC 62304 standard, like determining the software class (class A, b or C) and production of records, like software requirements mitigating risks and traceability matrixes.
On top of these two parts, risk analysis of software shall be realized with consideration to its environment. The main risk management process shall also contain risk management activities about interaction of software with hardware and its environment.
One symptom of a risk analysis that may not be accurate enough about interactions between hardware and software is the production of two separate risk assessment reports by the manufacturer, one for hardware and one for software.
Conclusion
To sum-up, the risk management process of ISO 14971 shall be applied as is to software. There is no bypass of any step described in the standard. More, there are additional activities described in IEC 62304 that are required for software risk management. Interaction of software with its environment shall also be analyzed to ensure a complete risk assessment.
