We validate machine learning libraries, tools, and applications for use in medical devices
“One can state, without exaggeration, that the observation of and the search for similarities and differences are the basis of all human knowledge.” – Alfred Nobel
Machine Learning Models in Medical Devices
In many data intensive domains, machine learning techniques outperform conventionally crafted software due to their ability to learn patterns from existing data. Well designed machine learning models can detect tumors in X-ray pictures, distinguish benign from malignant skin lesions and perform other very beneficial tasks.
In highly regulated markets like the medical devices market, however, any software that is part of a medical device – or that constitutes a medical device by itself – must be verified and validated before it gets approved for usage.
How is this different from traditional software validation?
Machine learning software does not only change the software development process completely, but in effect poses new challenges for the verification and validation of this software, most notably the following two:
Challenge 1 – Validation of the ML libraries
Virtually all machine learning models are trained instances of algorithms provided by public domain machine learning libraries or frameworks, such as TensorFlow, PyTorch, XGBoost, or others. As a result, the vast majority of – if not all – code of a machine learning model lives in the libraries from independent third party providers. These third-party libraries are called software of unknown provenance (SOUP) in the harmonized norm IEC 62304 Medical Device Software – Software Life Cycle Processes. SOUP must also be verified as part of the overall verification and validation process. As opposed to most libraries used by conventional software, machine learning libraries are not mere add-ons to the core software, but contain and run the essential algorithms of the resulting model, and must thus be verified following a SOUP validation plan. Or, as the FDA puts it in its Guidance on Off-The-Shelf Software Use in Medical Devices:
“For example, a commercially available neural network, used by a medical device manufacturer for pattern recognition, would require extensive validation if used in a Pap smear screening device, in computer-assisted radiology, or for computer-assisted analysis of ECG waveforms.”
Our Support
We have developed and implemented a concept for ML library validation. Our approach is applicable to the main commonly used libraries, such as TensorFlow, Keras, PyTorch, and XGBoost. It can be adapted with comparably little effort to your specific medical device project.
→ Read more about machine learning libraries in medical devices.
Challenge 2 – Validation of the entire ML pipeline
For a medical device containing machine learning software to get approved, the entire machine learning development process must be validated to comply with the regulatory requirements. For the European market, the requirements on software development are mainly specified in the harmonized norms IEC 62304 Medical Device Software – Software Life Cycle Processes and ISO 13485 Medical devices – Quality management systems.These requirements are heavily process-oriented, i.e. the medical device manufacturer needs to follow a well documented, state-of-the-art software development process to ensure the quality of the resulting software.
Because a typical machine learning development process – or pipeline in the machine learning lingo – differs significantly from a traditional software development process, the ML pipeline must be mapped to the processes described in the regulatory requirements, and each phase of the pipeline must be documented and justified in a way that allows auditors to understand and appreciate each individual design consideration and decision.
Our Support
We have mapped CRISP-DM to the IEC 62304 software development process for a better understanding of the overall picture and the regulatory requirements, and we have compiled a comprehensive set of validation documentation along a typical machine learning development process that exemplifies both how to properly build your validation documentation as well as how to check this documentation for correctness and soundness.
→ Read more about validation of the entire ML pipeline.