Software in Medical Devices, by MD101 Consulting

Here are the changes, compared to the draft version, already reviewed in this post.

Coud computing, Saas, Iaas, Paas

A section titled Definitions, not present in the previous version, was added. It clarifies the concepts of Coud computing, Saas, Iaas, Paas. These definitions are important to understand the discussions in the further parts of the document.

Especially the FDA clarifies that such software can be part of a quality management system, thus in the scope of software to be assessed for validation. Likewise, and not surprisingly, the FDA includes artificial intelligence systems in the scope.

Conversely, the FDA also clarifies that such software may not be part of a quality system, hence not in the scope of software to be validated. This is a recurring discourse of the FDA in this document. Some software won't require a validation because they're outside of the QMS scope.

We retrieve a new example of Saas in the last section of this guidance, illustrating the importance of taking into account such systems in the CSA process.

21 CFR part 11

The guidance stresses out the need to apply a risk-based approach on software validation versus part 11 requirements. This was not so well clarified in the previous version. We retrieve this recommendation twice:

• In V.A.(1) FDA recommends manufacturers focus the assurance effort on the features or functions relevant to the integrity of the records and 21 CFR Part 11 requirements applicable to the records intended to be stored.
• And at the end of V.B: This guidance recommends that manufacturers base their approach to computer software assurance on a justified and documented risk assessment and a determination of the potential of the system to affect product quality, patient safety, and record integrity.

Remark: 21 CFR part 11 is extremely difficult to apply by the book. It is in some cases technically impossible to apply it when the software wasn't designed for part 11. The FDA's solution to make use of a risk-based approach is therefore highly recommended!

High-risk and not high-risk

This is not a change: the FDA maintains its definitions for these two categories. It however clarifies what kind of risk-based approach the manufacturer should use:

• High process risk: the software failure may lead to a quality problem compromising safety.
  • the manufacturer should identify the assurance activities commensurate with the medical device risk.
• Not process high risk: the software failure won't lead to a quality problem compromising safety. Some other quality problems are possible.
  • the manufacturer should identify the assurance activities commensurate with the process risk.

Vendors evaluation

This is a new sub-section in the final guidance. While recognizing that manufacturers may have limited access to information from the software vendor as part of an assessment, the FDA recommends to assess the vendors capabilities, with methods like: audits, review of accreditations or certifications, review of their SW development practices, etc.

Like any other task present in this guidance, software vendor evaluation effort should make use of a risk-based approach.

Leveraging digital records

The FDA also recommends to leverage any existing digital record output of a software system. E.g.: system logs, audit trails...
In opposition of old-school (yet, still useful) paper and screen-shots, the FDA accepts such digital records as evidence of validation.
Manufacturers may leverage automated traceability, testing, and the electronic capture of work performed to document the results, reducing the need for manual or paper-based documentation.

Conclusion

No revolutionary change in this final guidance. It was mainly updated to clarify the recommendations. But also to add new examples of the digital age. Should we expect a new version of this guidance including example of CSA for artificial intelligence systems?