ISO 13485:2016 - the new revision has arrived!

What changed?

A lot of details and clarifications were added in many places. The most important are these:

• You are supposed to apply a risk based approach to all processes not only the products and product development.
• The design and development requirements have changed significantly, for example new requirements for the design transfer and design development files have been added.
• You have to validate software used to maintain your quality system

Risk based approach for processes

The standard requires now that all processes which are defined in the company shall be reviewed for potential risks. As a result of this the processes might be adopted to minimize the risks, new processes might be defined or the monitoring of the process might be changed. The risk assessment and changes of course need to be documented to have proof that the risk management has been done for the processes.

To define good processes you should at least

• Define and document the process itself (4.1.2 a)
• Define and document the input and output of the process, as well as references to related processes (4.1.2 c)
• Define and document methods to control the execution and results of the process (4.1.3 a)
• Perform a risk control for the process (what can go wrong, what are the effects if it goes wrong) (4.1.2 b)
• Document the identified risks
• Define and document the risk controls you can come up with
• Implement the risk controls by changing the process or the processes controls

Design and development requirements changes

For the design and development planning the standard now requires explicitly to define the methods used to ensure the traceability from design input to design output for each phase.

For the design and development inputs it now states specifically the usability requirements must be documented and that is must be possible to validate or verify the requirements.

For the design development verification and validation it is now required to include verification methods, acceptance criteria and, as appropriate, statistical techniques with rationale for sample size into the plans for verification and validation.

A new sub clause has been added for the design and development transfer. It requires that a procedure is established describing how to transfer from design and development to manufacturing. This procedure must describe how to ensure that the design outputs are suitable for production and how production capabilities can meet the requirements for the production.

Design and development changes should now also be evaluated for significance of the change to function, performance safety, etc. as well as impact on risk management input and output, products
A new sub-clause now states that design and development files now should be maintained for each medical device type. The file should reference or include the records which show the conformity to the above.

Validation of tools used to maintain your quality system

Matrix Requirements Medical can of course be validated according to ISO 13485:2016 and FDA 21 CFR 820. We support this process by providing our own verification and validation results as well as templates which make it easier for you fill the gap: You need to document the 'proof' that it fits your own procedures and processes. This support with additional validation templates you can adopt to your own needs. See also https://matrixreq.com/news/#20150701

IEC 62304 2015 - impact for Class A software

The 62304:2015 updates change a few things for class A software. While it makes it easier to segregate between class A and class B/C, it adds a bit of documentation work.

Segregation

It was now clarified that a software system can stay class A if it contributes to risks but there are risk controls outside of the software system (either in hardware or for example also class B/C software running on another processor).

The SOFTWARE SYSTEM is software safety class A if:
– the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or
– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which does not result in
unacceptable RISK after consideration of RISK CONTROL measures external to the
SOFTWARE SYSTEM.

Additional Requirements

Applying new new version comes with a price for the class A software you need to do the following if you choose to use IEC 62304

• there must be tests cases for the software requirements
• you need to manage issues found during testing
• you need to do regression tests after changes
• you need verify that the testing approach is god (e.g. that there is a complete and documented traceability to software requirements)
• you need to maintain the test records (e.g. with pass fail information, tester etc.)
• before releasing the device you need to make sure that the tests have been all done
• you need to evaluate and report known issues when releasing the device
• and finally analyze change requests before implementing them

Conclusion

The above actually looks like a quite a bit of additional work but if you follow any best practice or common approach for software development you will do most of the above work anyhow.

It seems the only exception would be highly agile processes where you move from one user story to the next until you think you are done. But in that case you can still easily extract some software requirements while you move along and link them to the user stories which you use for verification and you will be halfway there.