Les logiciels sont de plus en plus utilisés comme dispositifs médicaux, transformant le secteur de la santé dans le but d'améliorer les résultats pour les patients. Cependant, développer un logiciel en tant que dispositif médical implique de naviguer dans des cadres réglementaires complexes et évolutifs. Les cadres réglementaires peuvent compliquer le problème déjà complexe de l'innovation dans les logiciels et peuvent souvent faire peu de cas des distinctions entre logiciels, intelligence artificielle, apprentissage automatique et apprentissage en profondeur. Le développement dans chacun de ces domaines est connu pour progresser par sauts et pauses et peut se produire à tout moment, de la collecte de données aux tests, à la conception, au développement ou au déploiement. Pourtant, comme l'implication humaine offre des opportunités d'améliorations technologiques, les points de contact humains peuvent également conduire à des erreurs et à des préjugés. S'il était déjà arrivé que des décisions sur la protection de la propriété intellectuelle (PI) et/ou la diligence raisonnable puissent être effectuées de manière intermittente ou retardée, ce n'est pas le cas aujourd'hui dans le domaine des dispositifs médicaux basés sur des logiciels.

Cet article fournit une mise à jour sur la façon dont la FDA réglemente les logiciels en tant que dispositifs médicaux et explore les stratégies de propriété intellectuelle disponibles pour protéger les dispositifs médicaux basés sur des logiciels. La prise de conscience des changements à la FDA et de la manière dont ces changements peuvent influencer votre approche de l'Office des brevets est importante pour garantir un avantage concurrentiel à votre entreprise, mais également pour atteindre l'objectif déclaré d'améliorer les résultats pour les patients. Des erreurs et des biais peuvent être introduits à chaque point de contact humain, de la collecte de données à la mise en œuvre de l'algorithme. Les biais peuvent se traduire par de mauvais résultats pour les patients, et la FDA et les entreprises mettant en œuvre les meilleures pratiques chercheront en interne à éliminer ou à réduire ces biais. De manière analogue, une invention qui fonctionne pour éliminer les préjugés peut également être digne d'être protégée par un brevet et doit être identifiée tôt afin qu'une protection appropriée puisse être obtenue. L'évaluation continue de la recherche et du développement pour la propriété intellectuelle et les biais est la vague de l'avenir.

Réglementation de la FDA sur les logiciels en tant que dispositifs médicaux

La FDA classe les dispositifs médicaux en fonction des risques associés dans l'une des trois classes suivantes. Les dispositifs à haut risque de classe III nécessitent une demande d'approbation préalable à la commercialisation (PMA) autorisée en vertu de l'article 515 de la FFDCA avant d'être commercialisés, tandis que d'autres dispositifs peuvent être autorisés en vertu de l'article 510 de la FFDCA (à noter que, contrairement à l'article 515, les brevets sur les produits recevant une autorisation en vertu de l'article 510 ne sont pas éligibles à la prolongation de la durée du brevet).

Le logiciel en tant que dispositif médical (SaMD) est défini comme « un logiciel destiné à être utilisé à une ou plusieurs fins médicales qui remplit ces fonctions sans faire partie d'un dispositif médical matériel ». Les logiciels en tant que dispositif médical relèvent généralement de la catégorie 510k, mais déterminer si un produit individuel est un « logiciel en tant que dispositif médical » et est approprié pour une désignation 510k est une question au cas par cas et dépasse la portée de cet article. La FDA utilise des « attributs clés » pour identifier un SaMD, y compris le niveau de dépendance ou de confiance d'un utilisateur à l'égard des informations de sortie du dispositif médical. Notez cependant que la FDA gère une liste publique de dispositifs médicaux utilisant les technologies IA/ML approuvées par le Center for Devices and Radiological Health de la FDA. La liste comprend actuellement plus de 520 appareils, dont une grande majorité est autorisée sous la désignation 510 XNUMX. La FDA fait également une distinction entre les logiciels en tant que dispositif médical (SaMD), les logiciels intégrés à un dispositif médical (SiMD) et les logiciels utilisés dans la fabrication ou la maintenance d'un dispositif médical.

En partie en raison des défis liés au développement de l'IA mentionnés ci-dessus, la FDA adapte et teste des programmes pilotes pour tenir compte des risques et des changements rapides caractéristiques de l'industrie. Une récente commission sur l'IA a recommandé une approche de la réglementation de l'IA basée sur les risques, dans laquelle des réglementations « selon les besoins » s'appliqueraient aux applications d'IA présentant un risque négligeable pour la vie privée, la santé, la sécurité ou les droits fondamentaux. Le programme pilote de précertification de logiciels (pré-certification) de la FDA est un tel programme conçu pour rationaliser le processus réglementaire pour les développeurs de logiciels en tant que dispositifs médicaux (SaMD). Le programme repose sur l'idée que la réglementation devrait se concentrer sur le processus de développement plutôt que sur les produits individuels. Dans le cadre de ce programme, les développeurs SaMD peuvent demander une pré-certification, ce qui leur permettrait de commercialiser leurs produits sans passer par le processus d'examen traditionnel de la FDA. Au lieu d'examiner un dispositif médical terminé, la FDA évaluerait le processus de développement logiciel du développeur et déterminerait s'il répond à certains critères de qualité et de sécurité. S’il est autorisé, le développeur obtiendra une pré-certification, ce qui lui permettra de commercialiser ses produits SaMD plus rapidement et avec moins de contraintes réglementaires. Le programme pilote est actuellement en cours, avec plusieurs développeurs SaMD participant au programme.

S'engager dans un tel programme pourrait avoir un impact sur vos décisions stratégiques concernant votre propriété intellectuelle. Par exemple, comment une idée valable sera-t-elle identifiée et quand une demande de brevet sera-t-elle déposée ? Ces décisions pourraient ne pas être appropriées pour être retardées jusqu'à un dépôt 510K. De plus, une innovation que l'on pourrait préférer garder comme secret commercial peut inévitablement être révélée dans le cadre d'une diligence raisonnable continue. Afin de protéger les innovations logicielles, les entreprises qui conçoivent SaMD sont souvent confrontées à la décision de s'appuyer sur les secrets commerciaux ou la protection par brevet. Les deux approches ont leurs avantages et leurs inconvénients, et trouver le bon équilibre entre elles peut être crucial.

Protection de la propriété intellectuelle pour les logiciels en tant que dispositifs médicaux

Dans cette section, nous explorerons la protection de la propriété intellectuelle disponible pour les logiciels en tant que dispositifs médicaux. SaMD peut être couvert à la fois par des brevets d'utilité et des brevets de conception (couvrant l'interface utilisateur ou l'aspect et la convivialité du logiciel). La loi américaine sur les brevets entourant la protection des logiciels a acquis la réputation d'être plus stricte en matière d'éligibilité aux brevets logiciels, en particulier depuis la décision Alice. Pourtant, l'IA apparaît désormais dans 18 % de toutes les demandes de brevet d'utilité reçues par l'USPTO. En fait, de nombreuses fonctionnalités de SaMD sont encore brevetables, telles que de nouvelles méthodes pour améliorer la précision ou la fiabilité des diagnostics médicaux ou des plans de traitement, et des plates-formes logicielles adaptables qui peuvent être adaptées aux besoins spécifiques des patients ou aux contextes médicaux.

L'année dernière, en réponse à un décret sur la concurrence sur les prix des médicaments, les examinateurs de brevets de l'USPTO ont suivi une formation croisée avec la FDA pour rechercher toutes les informations que la FDA met à disposition sur les produits pharmaceutiques et les dispositifs médicaux. Certaines préoccupations ont été soulevées auprès des deux agences selon lesquelles les entreprises faisaient des déclarations incohérentes selon lesquelles leurs produits constituaient des changements modestes par la FDA, tout en revendiquant des innovations significatives auprès de l'USPTO. Nous notons cependant que des déclarations apparemment incohérentes peuvent survenir simplement parce que quelque chose peut ne pas être évident selon les normes de l'USPTO, mais néanmoins être considéré comme prévisible et sûr pour la FDA. L'impact de toute formation croisée reste à voir, et les examinateurs examinent actuellement les listes de l'Orange Book et d'autres informations accessibles au public dans les bases de données de la FDA. La coordination entre les déclarations adressées à la FDA et à l'USPTO souligne l'importance d'un processus rigoureux d'évaluation de la propriété intellectuelle tout au long du cycle de vie du développement du SaMD, de la conception à l'autorisation de la FDA, et est nécessaire pour protéger au mieux les innovations SaMD.

Comme alternative à la protection par brevet, les entreprises qui conçoivent des logiciels en tant que dispositifs médicaux peuvent rechercher des secrets commerciaux visant, par exemple, des algorithmes utilisés pour analyser des données médicales, un code logiciel propriétaire et d'autres informations confidentielles. Les secrets commerciaux font référence à des informations confidentielles qu'une entreprise garde secrètes pour obtenir un avantage concurrentiel. La voie du secret commercial pourrait renoncer aux coûts associés au dépôt d'une demande de brevet, mais les entreprises devront mémoriser et protéger les secrets commerciaux de la divulgation, notamment en mettant en place des procédures détaillées pour se protéger contre la divulgation des secrets commerciaux. Ce processus proactif d'identification de votre propriété intellectuelle et de mémorisation des secrets commerciaux, même en cas de retrait de la protection par brevet, est particulièrement utile lorsqu'un employé quitte l'entreprise et qu'un différend sur la propriété de la technologie survient. Un recours légal pour détournement d'un secret commercial est disponible if des mesures raisonnables sont prises pour protéger les secrets commerciaux, notamment en informant les employés que des secrets commerciaux existent dans l'organisation et en obtenant l'accord des employés qu'ils conserveront toute information confidentielle, y compris les secrets commerciaux, dans la plus stricte confidentialité. En règle générale, ces restrictions sont incluses dans les manuels des employés et les contrats de travail.

Stratégies pour naviguer dans le paysage réglementaire

Dans cette dernière section, nous fournirons une stratégie potentielle aux développeurs qui cherchent à naviguer dans le paysage réglementaire et juridique complexe entourant le logiciel en tant que dispositif médical. Comme ci-dessus, nous vous recommandons d'identifier de manière proactive votre propriété intellectuelle, ce qui peut impliquer de déposer des demandes de brevet tôt et souvent. Une idée peut être considérée comme mûre pour un brevet lorsqu'elle répond aux exigences légales de brevetabilité (telles que la nouveauté et la non-évidence) ainsi que est suffisamment développé pour être décrit dans une demande de brevet ; cependant, la maturité peut être une détermination difficile.

Une approche intéressante pour remédier à cette incertitude consiste à déposer une demande de brevet provisoire comprenant toutes les divulgations disponibles à ce moment-là et à mettre à jour le dépôt au cours de l'année de priorité au fur et à mesure que l'invention évolue ou que des données supplémentaires sont produites - un processus appelé "provisoire glissant". ” Une demande provisoire reste non publiée pendant un an, après quoi elle peut être convertie en demande de brevet d'utilité ou en demande internationale (PCT). En utilisant l'approche provisoire glissante, la demande provisoire initialement déposée est mise à jour avec les nouvelles données et la nouvelle divulgation, puis la nouvelle demande est déposée en tant que deuxième demande provisoire. Ce processus peut être répété tout au long de l'année de priorité à mesure que davantage de données et de divulgations deviennent disponibles, en déposant des demandes provisoires successives. Lors de la conversion de la première demande provisoire déposée en demande d'utilité ou en demande internationale, la demande d'utilité ou la demande internationale revendiquera la priorité sur toutes les demandes provisoires connexes déposées successivement et de cette manière, les modes de réalisation évolutifs développés au cours de l'année de priorité peuvent être protégés. Étant donné que les demandes provisoires ne sont pas publiées, le dépôt d'une demande provisoire peut également être utilisé pour commémorer la date de conception d'une invention ou pour commémorer un secret commercial. Par exemple, on peut mémoriser un secret commercial dans une demande provisoire et abandonner expressément la demande ou la laisser expirer en ne la convertissant pas en demande d'utilité ou en demande internationale. Par cette approche, la demande ayant le secret commercial ne sera pas publiée mais un enregistrement du secret commercial est enregistré auprès de l'office des brevets. Enfin, les meilleures pratiques consistent à compartimenter les idées que vous souhaitez conserver en tant que secret commercial. Cependant, si vous participez à un programme de précertification de la FDA, par exemple, et que vous divulguez involontairement un secret commercial, il existe un délai de grâce d'un an pour les divulgations publiques pendant lequel vous pouvez toujours déposer des demandes de brevet aux États-Unis (bien que ce délai de grâce ne soit pas applicable dans la plupart des pays en dehors des États-Unis).

En conclusion, le développement d'un logiciel en tant que dispositif médical est un processus complexe nécessitant une attention particulière aux cadres réglementaires de la FDA et de l'USPTO. Pourtant, en comprenant comment la FDA réglemente les logiciels en tant que dispositifs médicaux et la protection par brevet disponible, les développeurs peuvent créer des solutions innovantes qui améliorent les résultats pour les patients tout en protégeant leur propriété intellectuelle.

https://www.fda.gov/medical-devices/digital-health-center-excellence/software-medical-device-samd

https://www.uschamber.com/technology/u-s-chambers-ai-commission-report-highlights-the-promise-of-ai-while-calling-for-a-risk-based-regulatory-framework

Alice Corp. Pty. Ltd. c. CLS Bank Int'l – 573 US 208, 134 S. Ct. 2347 (2014)

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Automobile / VE, Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• GraphiquePrime. Élevez votre jeu de trading avec ChartPrime. Accéder ici.
• Décalages de bloc. Modernisation de la propriété des compensations environnementales. Accéder ici.
• La source: http://knobbemedical.com/medicaldeviceblog/article/navigating-the-regulatory-landscape-fda-approval-and-patent-protection-for-software-as-a-medical-device/?utm_source=rss&utm_medium=rss&utm_campaign=navigating-the-regulatory-landscape-fda-approval-and-patent-protection-for-software-as-a-medical-device