Le guide étape par étape du processus de validation logicielle de la FDA

En janvier 2002, la Food and Drug Administration a publié une directive intitulée «Principes généraux de la validation des logiciels ; lignes directrices finales à l'intention de l'industrie et du personnel de la FDAf'. À ce jour, cette directive est utilisée comme un document essentiel pour la supervision et la validation des logiciels médicaux, et c'est sur cela que nous nous concentrerons dans cet article.

Il convient de mentionner ici que le 4 novembre 2021, la FDA a publié un document susceptible de transformer le visage de la validation/vérification des logiciels médicaux et de tout processus connexe. «Contenu des soumissions préalables à la mise sur le marché pour 2 fonctions logicielles de dispositif» est désormais public dans sa version préliminaire, ouverte aux commentaires uniquement, les retours étant collectés jusqu'à la fin de 2022.

Comme pour les précédents articles, cet article de blog a été préparé en collaboration avec Krzysztof Minicki, Directeur Santé et Sciences de la Vie chez Spyrosoft.

Qu'est-ce que la vérification des logiciels médicaux selon la FDA ? 

The goal of the medical software verification is to prove that our specified software requirements are consistent, complete and have been properly implemented, and our medical applications work as planned. It serves as confirmation that what we planned to do when it comes to the software implementation has been carried out as required.  

To give you an example, if the application I developed was to provide a daily/weekly/monthly report for my patients’ saturation, temperature, blood pressure in a specific format, then the verification will mean that the application is, in fact, able to generate the report as required. 

Qu'est-ce que la validation des logiciels médicaux selon la FDA ? 

La validation doit confirmer – par une série d'activités diverses aboutissant à des preuves objectives et mesurables – que le logiciel médical développé remplit sa fonction telle que décrite dans l'Usage Prévu et qu'il est efficace et sûr à utiliser. As with verification, validation is also accomplished through a series of activities to check if the specific groups of requirements have been implemented consistently, completely and as a set of functionalities. This process is focused on providing evidence that the implementation effectively and properly fulfils the requirements and the intended use for this specific medical software.  

Going back to the example, we would have to show the report to a doctor that will be using it, and they would have to confirm that this will be – in fact – useful, clear, accessible and aligned with the initial medical expectations. The clue here is delivering an external validation for our medical software. 

Pourquoi – en pratique – la vérification et la validation ne sont-elles pas si différentes l'une de l'autre ? 

Ce qu'il est important de mentionner ici, c'est que le «General Principles of Software Validation; Final Guidance for Industry and FDA staff » nous guide à travers les processus de vérification et de validation. 

While the verification and the validation have both been separated in the medical sector documentation, in practice – the division is arbitrary at times. It makes sense from a business perspective, though – as it clearly divides the responsibilities between our customers and our team. Once we receive the specifications, the requirements and a list of functionalities from a customer, we can then use those to develop medical software and then verify it using manual and automated tests as well as other activities.  

Une fois le produit prêt, nous pouvons le remettre au client pour qu'il le valide, bien que des validations à petite échelle puissent être réalisées tout au long du processus de développement. 

IQ/OQ/PQ – les aspects fondamentaux de la validation des logiciels médicaux 

La FDA précise 3 axes qui seront déterminants pour la validation des logiciels médicaux. Si vous disposez d'un logiciel médical, vous devez être en mesure de le valider et de le vérifier selon ces 3 perspectives :

Qualification d'installation (IQ) 

Vous pouvez installer et utiliser le logiciel en toute sécurité. 

La qualification d'installation (IQ) est définie par la FDA comme «établissant la confiance que les équipements de process et les systèmes auxiliaires sont conformes aux codes appropriés et aux intentions de conception approuvées, et que les recommandations du fabricant sont dûment prises en compte’. 

Qualification opérationnelle (QO) 

Le logiciel dispose d'une fonctionnalité opérationnelle complète, ou comme l'indique la FDA, «établir la confiance que les équipements de processus et les sous-systèmes sont capables de fonctionner de manière constante dans les limites et tolérances établies'. 

Qualification de performance (QP) 

Le logiciel est efficace, accessible et performant même avec une charge de travail accrue. La FDA le définit comme ‘établir la confiance par des tests appropriés que le produit fini issu d'un processus spécifié satisfait à toutes les exigences de mise en production en matière de fonctionnalité et de sécurité’. 

Quels sont les principes de la validation logicielle ? 

The most important are the requirements – especially those related to the system – as they will be later used as a basis for validation. System requirements are later divided into software requirements, software architecture, software components, then again into more specific software requirements and details designs.  

La validation logicielle doit être planifiée au niveau du cycle de vie logiciel. Le plan lui-même doit être adapté à une application médicale spécifique, à sa classe et à ses risques. L'effort sera plus important pour les logiciels présentant un risque plus élevé et de classe II-III.  

Au niveau de la planification, nous devons également établir comment nous souhaitons aborder les bugs et les défaillances logicielles inévitablement liés au processus de développement logiciel. Pour ce faire, nous devons répondre à cette question : 

• Comment voulons-nous corriger ces bugs et comment vérifierons-nous et validerons-nous les corrections ? 

As for the validation process itself, we need to check whether the requirements, including those specific ones listed above, are what was eventually built and delivered during the software development process. We also need to explain in the documentation not only if each of these requirements were addressed but also how it was done. This is usually resolved by a list of requirements registered within a matrix with a list of ways and specific functionalities that we developed to address these requirements. This register should also include test cases for each requirement/functionality. 

Une fois la matrice complétée, l'une des étapes de validation peut être considérée comme réussie. 

Il est toutefois important de rappeler que la validation ne concerne pas les tests eux-mêmes. Au contraire, tout test doit également être approuvé et validé avant d'être utilisé pour un projet. 

Comment aborder toute modification du produit ? 

Another thing we should plan for is how we will approach any change to our original build and to what extent we will test our medical software after releasing these changes to production. Conducting extensive testing after a minor change may not be necessary, but we should clearly state what our approach will be after a small adjustment. You may need to conduct an analysis to estimate the impact this adjustment has on our software and the risk for the system as a whole. Based on the results of the analysis, you can then plan our next steps, including regressive tests, to ensure that the change is properly validated and verified. 

The extent of our validation and verification strategy will largely depend on the level of risk and the complexity of our software. The less risk it poses to the patient, the simpler our strategy can be. Eventually, we have to be able to prove that all criteria set at the planning stage have been met. 

What’s particularly important is the fact that both the validation and the verification process should be conducted by independent group of specialists from your company or a third-party body. It often happens that the verification is done internally by the software provider, and the validation process is conducted by the company that requested the software to be developed – it is not a rule, though. In practice, both parties cooperate to complete the processes at various stages of development.  

Pour chaque étape des processus, nous devons également définir des critères d'acceptation – en bref : l'entrée doit correspondre à la sortie. 

Études des facteurs humains – l'étape finale du processus de validation 

If you’re a medical software provider, you’re obligated to conduct human factor studies as the crucial step of the validation process. Software is then tested using a simulated environment, yet with a group of its potential end-users. This group of users must be selected carefully taking into consideration factors such as age, race, gender, educational background, language and location. There are two types of HMS depending on when they are conducted: 

• Études formatives sur les facteurs humains menées au début du processus de développement, 

• Études sommatives sur les facteurs humains réservées à la phase finale du processus de validation. 

Ces études permettent de valider si le produit final est utile, accessible et conforme aux exigences. Les sessions sont ensuite synthétisées dans un rapport sur l'utilisabilité du produit médical, y compris le logiciel. 

À vous de jouer 

Vous avez besoin d'aide pour valider votre logiciel médical conformément aux exigences de la FDA ? Contactez notre Directeur Santé et Sciences de la Vie, Krzysztof Minicki, et son équipe à l'adresseLinkedIn ou via notre site web.