The ability to apply flexibility in certain places of a standard makes a lot of sense, and the risk management file is the perfect place to keep the records justifying the decisions.
Yet, if you find risk management confusing in real application, you are not alone. The reason is not because you lack skills or experience – instead embedding risk management in IEC 60601-1 is a fundamental mistake for three reasons.
First is simple logistics. The correct flow is that the risk management file (RMF) studies the issue, and proposes a solution. That solution then forms a technical specification which can be evaluated as part of a product standards like IEC 60601-1, particularly those places where the standard allows or requires analysis. When the verification tests are successful, a report is issued. The RMF can be completed and the residual risk judged as acceptable. This forms a kind of mini V-model:
Embedding risk management in a product standard creates a circular reference which can never solved - the RMF cannot be signed off until the product report is signed off, the product report cannot be signed off until the RMF is signed off. This is more than just a technicality – it debases and devalues the risk management by forcing manufacturers to sign off early, especially when test labs are involved.
Which leads us to our second problem: Third party test laboratories are valuable resource for dealing with key risks such as basic electrical safety and EMC. But they are ill equipped to deal with subjective subjects, and ISO 14971 is whopper in the world of subjectivity: everyone has their own opinion. The V-model above isolates the product standard (and third party test labs) from the messy world of risk management.
Which brings us to our third problem – the reason why risk management is so messy. Here we find that ISO 14971 that has its own set of problems. First, there are in practice too many risks (hazardous situations) to document in a risk management file: the complexity of a medical device design, production process, shipping, installation, service, interfaces between the device and the patient, operator and the environment contain tens of thousands situations that have genuine risk controls. ISO 14971 fails to provide a filter for isolating out those situations worth documenting.
Secondly is the rather slight problem that we can’t measure risk. Using risk as the parameter on which decisions are made is like trying to control the temperature of your living room using a thermometer with an accuracy of ±1000°C. Our inability to measure risk with any meaningful accuracy leads to a host of other problems to long to list here.
Yet In the real world we efficiently handle tens of thousands of decisions in the development and production processes that involve risk - it’s only the relatively rare case that we get it wrong.
The answer may lie in “risk minimum theory”, which is planned to be detailed further on this site at a later date. This theory provides a filter function to extract only the risks (hazardous situations) worth investigating and documenting in the risk management file, also provides a way to make risk related decisions without measuring risk.
In the mean time, we need to deal with ISO 14971. This article recommends:
Don’t panic – everybody is confused!
Follow the minimum requirements in the standard. Even if you don’t agree or it does not make sense, make sure every document or record that is required exists, and that traceability (linking) is complete. Use a checklist showing each discrete requirement in ISO 14971 and point to where the your records exist for that requirement. Keep in mind that the auditors and test engineers didn’t write the standard, but they have to check implementation, so following the standard - even if blindly - helps everyone.
Watch carefully for the places where the standard says a record is needed, and where verification is needed. There is a difference – a “record” can be as simple as a tick in a box or a number in a table, without justification. “Verification” means keeping objective evidence. Verification is only required in selected places, which may be a deliberate decision by the authors to try and limit overkill.
Develop your own criteria for filtering what goes in in the file. The risk minimum theory concludes that that risk controls which are clearly safe, standard practice, and easy for a qualified independent person to understand by inspection do not need to be in the file. Risk controls that are complex, need investigation to know the parameters, borderline safety or balanced against other risks should be documented.
As an exception to the above, keep a special list of requirements in product standards like IEC 60601-1 that specifically refer to risk management, including a formal judgement if they are applicable (or N/A), and a pointer to the actual place in the risk management file where the item it handled. Again this helps everyone – manufacturer, auditors and test engineers
Be aware that there are three zones in safety: the green and red zones, where there is objective evidence that something is either safe or unsafe, and a grey zone in between where there is no hard evidence either way. In the real world, 99% of risk controls put us in the green zone; but there are still 10-100 that inevitably fall in the grey zone.
If you are in this grey zone, watch out for the forces that influence poor risk management decisions: conflicts of interest, complexity, new technology, competition, cost, management pressure and so on. Don’t put a lot of faith in numbers for probability, severity, risk or criteria, be aware of camouflage - a warning in a manual magically reducing the risk by 2 orders of magnitude, masking the real risk control. Dig deeper, find the real risk control, and then decide if it is reasonable.